Although we personally trusted and would've moved forward with Moxie's informal permission to distribute SignalProtocol within ChatSecure on the App Store, our funder required us to get the legal details squared away or we'd lose our funding. This announcement is an amazing gift for us, and for other GPL compatible Mac/iOS apps.
This announcement also more broadly benefits the copyleft community. There has been a decline in GPL apps on Apple platforms, particularly because of this conflict between the GPL and Apple's App Stores. It makes it clumsy to accept pull requests because you need a CLA to allow relicensing for distribution. There's a also lot of FUD from anti-Apple copyleft zealots. Having a good template for other developers who wish to stick to strong copyleft without worrying about App Store issues is a great contribution to the Apple-friendly copyleft community.
Apple could always do what Google does, to state that in the case of copyleft licenses their term take precedence over the ToS (neutralizing restrictive terms like the redistribution ban on everything you download from the store).
This meme keeps going around that the Android store is GPL compatible. But where is the actual license text that allows this, or at least how does the situation differ from that with iOS? I checked the current Google Play Terms of Service and the iTunes Terms and Conditions. The two were alike in several respects:
- They had no blanket exception or deference I could find to third party agreements, nor any relevant mention of the terms "open source" or "copyleft".
There is something in the Google ToS that could be interpreted as such an exception, but the wording gives it dubious applicability to third party apps, and in any case, the Google Play ToS says that "if there is any conflict between the Google Play Terms of Service and the Google ToS, the Google Play Terms of Service shall prevail".
- They dictated various random usage rules, again without any explicit exception clause.
- One of those rules was a requirement not to circumvent DRM. AFAIK, both app stores do in fact store apps obfuscated/encrypted on disk, so it wouldn't be possible to usefully redistribute the apps without engaging in such circumvention. (The requirement was in each case worded broadly enough to potentially apply to any DRM included with the app itself, though this is just another example of a random potentially-conflicting usage rule.)
- However, they both state that apps are licensed directly from the developer to the user, with the store distributing them on the developer's behalf, rather than licensed to the store and sublicensed from there to the user. (If that even means anything.) Therefore, it could be argued - I don't know how much validity this would have, but it could be argued - that the GPL's "you may not impose any further restrictions" clause is not in fact violated, because you (i.e. the app developer) are not imposing any further restrictions - the restrictions come from a separate contract you're not a party to - and Google/Apple is not bound by the terms because it's just distributing stuff on your behalf rather than on its own authority.
Therefore, on both stores GPL compatibility is possible but dubious. Where is the difference?
(By the way, I've been lazy and haven't checked the respective developer agreements. It's possible that one or both agreements have clauses that impede legally submitting GPL apps to the store, but they can't generally authorize behavior that the ToS forbids - since users are not party to them - so any such difference wouldn't affect my main point about the Play Store having similar restrictions to what people have complained about wrt the iOS App Store.)
Source:
== The Google ToS clause ==
Open source software is important to us. Some software used in our Services may be offered under an open source license that we will make available to you. There may be provisions in the open source license that expressly override some of these terms.
Capturing of Streams. You may not use Google Play or any Content in conjunction with any stream-ripping, stream capture or similar software to record or create a copy of any Content that is presented to you in streaming format.
Use of Android Apps. You must use apps from Google Play in accordance with the Google Play Business and Program Policies which are in place from time to time, the current version of which can be found at http://play.google.com/about/android-developer-policies.html
Apple:
(ii) If you are a commercial enterprise or educational institution, you may download and sync an App Store Product for use by either (a) a single individual on one or more iOS or tvOS Devices used by that individual that you own or control or (b) multiple individuals, on a single shared iOS or tvOS Device you own or control. [..] For the sake of clarity, each iOS or tvOS Device used serially or collectively by multiple users requires a separate license.
== No DRM circumvention ==
Google:
Security Features. You may not attempt to, nor assist, authorise or encourage others to circumvent, disable or defeat any of the security features or components, such as digital rights management software or encryption, that protect, obfuscate or otherwise restrict access to any Content or Google Play. If you violate any security feature, you may incur civil or criminal liability.
Apple:
You agree that the App and Book Services and certain App and Book Products include security technology that limits your use of App and Book Products and that, whether or not App and Book Products are limited by security technology, you shall use App and Book Products in compliance with the applicable usage rules established by Apple and its principals (“Usage Rules”), and that any other use of the App and Book Products may constitute a copyright infringement. Any security technology is an inseparable part of the App and Book Products. Apple reserves the right to modify the Usage Rules at any time. You agree not to violate, circumvent, reverse-engineer, decompile, disassemble, or otherwise tamper with any of the security technology related to such Usage Rules for any reason—or to attempt or assist another person to do so.
== On who is licensing apps to whom ==
Google:
When you buy “Content” (defined as data files, applications, written text, mobile device software, music, audio files or other sounds, photographs, videos or other images) on Google Play you will buy it either:
[..]
(c) in the case of Android apps, from the Provider of the app (an “App Sale”).
Each time that you purchase Content, you enter into a separate sale contract:
[..]
(f) with the Provider of the Content you have purchased (in the case of App Sales).
The separate sale contract in (e) or (f) above (as applicable) is in addition to your contract with Google Inc. for the use of the Service (i.e. these Google Play Terms of Service).
Apple:
You acknowledge that: you are acquiring the license to each Third-Party Product from the Application Provider; Apple is acting as agent for the Application Provider in providing each such Third-Party Product to you; and Apple is not a party to the license between you and the Application Provider with respect to that Third-Party Product.
(warning: the Apple ToS has separate sections with similar terms for media and apps, and there is also a "Licensed Application End User License Agreement" that specifies it's merely a default for apps without their own terms, so make sure you look in the right sections.)
> 3.8: You agree that Google and/or third parties own all right [...]. You agree that you will not, and will not allow any third party to, (i) copy, sell, license, distribute, transfer, modify, adapt, translate, prepare derivative works from, decompile, reverse engineer, disassemble or otherwise attempt to derive source code from the Products, unless otherwise permitted
And primarily 4.2, which you already found: In the event of a conflict between the Terms and any such licenses, the open source software licenses shall prevail with respect to those components.
> You may not sell, rent, lease, redistribute, broadcast, transmit, communicate, modify, sublicense or transfer or assign any Content or your rights to Content to any third party without authorization
> And primarily 4.2, which you already found: In the event of a conflict between the Terms and any such licenses, the open source software licenses shall prevail with respect to those components.
No, I didn't find that, I found a similar clause in the overall Google ToS which, as I said, didn't seem like it would be applicable to third party applications. I see, this is what you were referring to. 4.2 would definitely qualify as the kind of blanket exemption I was looking for - if it is actually in effect.
Interesting. Your first link is not the Google Play ToS; it's your second link which calls itself the "Google Play Terms of Service", while your first link is the "Android Market Terms of Service", and does not contain the text "Google Play". But "Android Market" is a dead brand. And a relevant-looking page on android.com contains links to the Google Play ToS and other agreements, but not your Android Market ToS:
I suppose that the failure of the new ToS to include similar language is probably a mistake, as is the fact that the Play ToS contains so many terms (like the stream ripping clause I quoted) that seem like they're intended for media rather than apps, but have no explicit limitation to the former. But that doesn't change the fact that the ToS is what it is, and has been for years, yet people still upload GPL stuff.
Also, if Google were to fix this it wouldn't just be a matter of adding the clause back. As I mentioned, from what I can tell (not an Android user myself), Google Play encrypts APKs at rest as a DRM measure; since modifying and redistributing them would require cracking the encryption, the Play ToS's anti-DRM-circumvention clause is presumably an "additional restriction" from the GPL's point of view. (If we ignore the who-contracts-with-whom question I raised, at any rate.) Giving the GPL priority prevents incompatibility, but Google presumably wouldn't want there to be a loophole where crackers could legally reverse engineer the DRM that applies to all apps by claiming to do it for the purpose of distributing a GPL app. This wasn't an issue in 2011 because the encryption feature hadn't been released yet; the Market ToS has an anti-circumvention clause too, but if there is no actual DRM to circumvent, there's no issue.
Of course, there is a solution: Google could just allow developers to turn off DRM on a per-app basis. But they'd have to care enough to implement that.
Which is essentially the same problem as with Apple. I said that Google's and Apple's ToSes were alike in enforcing random usage rules on apps with no exceptions, but there's a difference in quantity: since Apple's has separate sections for iTunes proper and the App Store, it doesn't have the same kinds of probably-not-intended-to-apply rules as Google's. In fact, aside from DRM clauses, the only restrictions in Apple's ToS that apply to third-party apps distributed with their own ToS are four paragraphs of "APP STORE AND APP STORE FOR APPLE TV PRODUCT USAGE RULES", of which two are a prohibition on using the same iTunes account on multiple commercial or multi-user devices, and the other two are essentially a description of DRM limitations. If Apple wanted to properly support GPL on the store, it would have to add an option for developers to disable DRM on their apps, same as Google, but then legally speaking it wouldn't need to add any dangerous-seeming blanket exception clause; it would just need to add an exception to those four paragraphs. Again, a matter of caring.
Historically, Google has cared a lot more about open source and particularly the GPL while Apple has kind of turned up its nose - but then, historically, Apple was under different management than it is today. Maybe I should try filing a Radar.
Outside of the name calling, what FUD would that be? Are we uncertain if apple apply an app-store license on apps they distribute? Are we uncertain if user can or can't install their own modified version of apps on their devices?
The license change is from GPLv3 to, uh, dual GPLv3/MPL-on-the-App-Store-or-something?
> Additional Permissions For Submission to Apple App Store: Provided that you are otherwise in compliance with the GPLv3 for each covered work you convey (including without limitation making the Corresponding Source available in compliance with Section 6 of the GPLv3), Open Whisper Systems also grants you the additional permission to convey through the Apple App Store non-source executable versions of the Program as incorporated into each applicable covered work as Executable Versions only under the Mozilla Public License version 2.0 (https://www.mozilla.org/en-US/MPL/2.0/).
Tough crowd! That's what we used to do, but some extremely vocal people weren't satisfied, so we've done this to integrate our intentions into the license itself.
Was this lawyered? Because the clause reads to me like Programmer Law.
> Provided that you are otherwise in compliance with the GPLv3... [we] also grants you the additional permission to convey through the Apple App Store non-source executable versions of the Program as incorporated into each applicable covered work as Executable Versions only under the Mozilla Public License version 2.0
1. The phrase "only under the [MPL]" definitely means my app store binary isn't distributed under the GPL
2. The phrase "Provided that you are otherwise in compliance with the GPLv3" does not seem to have any effect for distributing "only under the MPL". By distributing software "only under the MPL", I do not "otherwise" have GPLv3 obligations for me to not be "in compliance with".
3. Unless you intend to say that I have both GPLv3 and MPL obligations, in which case the same GPL obligations which [allegedly] prevented me from using this in the app store are still in effect. Also, this would contradict 1.
Please have a lawyer look at this. I guarantee my clients' legal counsel would not allow use of a library under these terms.
Oh, I totally missed that the MPL makes you deliver source with binaries. I think I had it confused in my head with the Apache License 2.0 somehow.
OK, I'll admit that this is in fact clearer than the Mosh approach. (My main confusion was whether you expected me to offer source if the only binary I distributed was an iOS app; the Mosh waiver is very clear about that.)
"Provided that you are otherwise in compliance with the GPLv3 for each covered work you convey (including without limitation making the Corresponding Source available in compliance with Section 6 of the GPLv3)..."
Yes, the expectation is that you still have to comply with the GPLv3 (including making the corresponding source for your derivative work available), at which point you have the additional freedom to distribute the app through the app store.
I think the additional permissions is a quite a nice way to do it, since it enables compatibility without creating new licenses. It follow the same path that LGPLv3 does by being gplv3 with an additional permission.
From my perspective as a developer, that is quite scary. While I love mosh, I don't trust anyone in this world enough to hand them a loaded gun labeled "GPL violation that was excused informally".
Still, IMO we just shouldn't support devices that don't allow you to distribute canonical free software freely.
That's too bad, while I'm happy with Signal, I understand where people using LibreSignal are coming from and it'd be a shame to be unable to talk to them (or install yet another freaking app for it).
It's hard to imagine there are enough LibreSignal users to make a notable impact on the OWS infrastructure in terms of expenses. Though over time, that could change, especially if other forks joined the party, and of course the fallout of shutting them out would only grow over time.
Given OWS's worries about federation and shared standards standing in the way of progress, they might want to avoid third party access simply because it might stop them from changing the server interface. Thirds party clients would be at the mercy of their developers when OWS makes an incompatible change. Caveat emptor, I would say, but again, the problem would only grow.
My personal situation is that the only people I talk to via Signal are nerds; the kind of people who jump ship when a sexier alternative comes up -- like we did when TextSecure/Signal offered good e2e crypto. But that's stopped being a unique feature since WhatsApp also uses the Signal Protocol, which simultaneously made it feel much less pressing to convince non-nerds to switch from WA to Signal.
> Given OWS's worries about federation and shared standards standing in the way of progress, they might want to avoid third party access simply because it might stop them from changing the server interface.
Totally. Client interoperability as well. For us, the problem is that when a 3rd party client breaks compatibility, that doesn't just affect the users of those 3rd party clients, but the normal Signal users who communicate with them as well.
For example, LibreSignal doesn't support voice calls. When normal Signal users try to call LibreSignal users, it just doesn't work. Most normal Signal users don't care or understand or sympathize with the idea that the person they're trying to call uses some other app which doesn't support voice calls. They'll just think that Signal voice calls are flaky and randomly don't work sometimes.
That's one example, but as development progresses, there will inevitably be more. We're concerned about exactly the same set of problems we found with federation.
> But that's stopped being a unique feature since WhatsApp also uses the Signal Protocol, which simultaneously made it feel much less pressing to convince non-nerds to switch from WA to Signal.
Just to be clear, I think that's great. If people don't feel it's necessary to use Signal because Signal Protocol is "the new normal" in the apps they already use, then I think we've succeeded. Hopefully we'll eventually have the chance to push the envelope forward again and restart that cycle.
I think they're talking about the protocol like "keep around these keys and exchange this", but implemented with proprietary code that doesn't use any of Moxie's C implementation which is indeed GPL.
Probably, but most people aren't going to understand that LibreSignal is different from Signal. We could try to make things work differently for users calling LibreSignal, but that sets us on a path of having to constantly account for all the various 3rd party clients and their various stages of development or support, which as a team of two developers we unfortunately don't have the resources for.
> My personal situation is that the only people I talk to via Signal are nerds
Nerds, and people who were pressured to install Signal by nerds, indeed cover nearly all of my Signal contacts. But that second group is the larger one, so "nerds" is not an entirely fair characterisation of Signal's user base any more.
Yep, the rest of the world has moved on. Olm already provides what Signal protocol did and the app itself is now useless to many.
Signal app itself still can't run on Android Open Source, because it forces centralised metadata collection on the user via Google Play Store and GCM. Installing Google privacy-invading bloatware, is a prerequisite, which also further requires you to destroy your phone's security model because all non-vendor GCM options currently require you to patch a nasty hack into the kernel or otherwise prevent you using a secure, verified bootloader.
But like 'blame Apple', 'blame Google', because Signal won't provide or permit a WebSocket fallback (to do exactly the same as desktop client) - the one major thing LibreSignal wanted and were threatened legal action with if they did. Oh, that and using a trustworthy (FDroid), not just trusted, app store that doesn't require bloat, metadata leaks & GSF battery drain.
So, if your operating system can't support GCM (for good security reasons), or you just don't want to give up your data (kind of the point of Signal), then you're out in the cold.
You may think "It's open source, I'll run my own server". Nope. It's not just that they won't allow others to federate with their servers. Even if you were willing to give up your entire network of Signal contacts (that you've been building because you THOUGHT they were Open as they always painted themselves) - you can't. 'Open' Whisper aren't open sourcing their server. The voice side is locked up. Don't forget, you didn't choose GCM. Signal took the SMS option away after you'd built your network, plus convinced all your friends to drop XMPP alternatives and install Signal.
This license is too little, too late.
Matrix.org is providing a secure, viable modern, open alternative to IRC and XMPP, that also federates with them. With clients like Vector.IM that'll soon be non-GCM too. It already provides better functionality than Signal app and with Olm protocol (being merged within weeks) is equivalent to Signal encryption anyway.
Conversations.IM already works beautifully without Signal (plus is merging with the resources of ChatSecure). They've proven very well that you CAN in fact have an awesome (and secure) user experience based on XMPP.
The thing that really annoys me, is that while we spent all these years just backing Signal, singing their praises - thinking they were open (yeah, more fool us) - we were also diverting attention, installs and sentiment/resources from genuinely open protocols & projects for the web. Now those networks are gone, they're hard to get back.
The good news is that Matrix is technically good enough to win, so I hope they do.
Why have Signal Protocol chosen now to open the license up a little? Well, I can't help but wonder if it's because Olm is finally ready, done and merging for public release.
* Olm isn't a replacement for 'Signal protocol' - it's just an independent (Apache license) implementation of the same 'double ratchet' cryptographic ratchet that Signal protocol uses under the hood for generating message keys.
* Megolm provides the higher layer semantics for using Olm for group conversations in Matrix, and diverges significantly from Signal Protocol as far as I know.
* There's already an experimental FDroid ready build of Vector Android (following the HN discussion on Friday) at https://matrix.org/jenkins/job/VectorAndroidDevelop/lastSucc... - feedback welcome on just how badly the polling-based push mechanism performs on your hardware & network. We're looking at alternative push mechanisms like microG - or just using a more efficient push transport for Matrix to provide notifs.
Thanks @Arathorn. That's great to hear an FDroid candidate's available. Great turn around! The only device I'd have to test it on right at the moment, unfortunately doesn't take 3rd party APKs (FDroid's been signed, but I'm reluctant to otherwise open that particular device). Will see what else I can pull together. I could sign the APK with my own OS build, but then I'd miss OTA updates (so a different security risk). MicroG sounds a good option. As for Copperhead specifically, I don't think MicroG will be on the table for a while though. Another push would be ideal I suppose (but I know you need to balance priorities).
Hi @Arathorn, the battery drain of that experimental build is certainly noticeable, but not disastrous. In 18 hours on a new Nexus 6p, it's drained the battery 30%. Conversations.IM by comparison had only drained 1%. The next biggest battery drain on that device to Vector, had only taken 3%. I think it's still viable enough for an early release to FDroid for the time being, but with a warning. The fact that you can also turn its background sync on or off, means it's quite fine for the casual reading use case, without notifications one.
On second look, MicroG won't be a good option at all.
It requires signature spoofing.
(i.e. security to be broken in various ways. Opens it up to all sorts of other attacks, plus to even install, forces rooting the device, or running Xposed, or applying dodgy kernel hacks and prevents using verified boot, which is a sensible security requirement).
> Yep, the rest of the world has moved on. Olm already provides what Signal protocol did and the app itself is now useless to many.
Olm/Megolm is not Signal Protocol. It is an entirely different protocol that has made different choices, and those choices have received less study and scrutiny. It hasn't been deployed anywhere that I know of. It's fine if you want to explore those choices, but I would caution against calling it the same thing.
> the one major thing LibreSignal wanted and were threatened legal action with if they did
I understand that because we have what you consider to be unpopular opinions, it's easy to believe that we're somehow single-handedly responsible for everything bad in the world. However, you can't just make shit up. Legal action? Could you cite that?
The entirety of our exchange is in the top of that issue. They asked for permission, and I said we'd prefer for them to use their own servers and their own name. The same thing we say to everyone. Many people do set up their own servers for their own products, these people chose not to. We didn't threaten anyone with anything, legal or otherwise.
> 'Open' Whisper aren't open sourcing their server. The voice side is locked up.
By "the voice side," do you mean a TURN server? Plenty of options for you out there. Or are you just more interested in having something to blame us for?
And LibreSignal already doesn't support voice, even with our servers, so your complaint doesn't make much sense.
> Why have Signal Protocol chosen now to open the license up a little? Well, I can't help but wonder if it's because Olm is finally ready, done and merging for public release.
The conspiracy theories never stop. We haven't changed anything, this has been what we said our policy was all along, but people thought that was some kind of conspiracy. Of course, now that we've made it an explicit license term instead, that's also suspicious somehow. Why would anyone ever want to be involved in this community you think we're not appropriately considering?
Come on @moxie, you didn't just say you'd prefer them not to, you expressly forbid it:
"I'm not OK with LibreSignal using our servers, and I'm not OK with LibreSignal using the name \"Signal.\" You're free to use our source code for whatever you would like under the terms of the license, but you're not entitled to use our name or the service that we run." (https://github.com/LibreSignal/LibreSignal/issues/37#issueco...).
You know full well that it's illegal to use systems without authorisation. In the US, it's called the Computer Fraud and Abuse Act and they'd be committing a criminal offense, with severe penalties, if they did (and government could prosecute with or without OWS consent, as AaronSw experienced). There's also an open ended civil claim you'd now have against them. So whether express or implied, the project from then on, was under a direct cloud of legal threat.
'LibreSignal' never wanted their own "product" as you choose to call it. No one in that community was trying to compete with you. They just had legitimate security needs, or wanted to use Signal as it was, but without being tied to an advertising company. The App Store risks aren't even theoretical or tin-foil-hat material: https://twitter.com/SwiftOnSecurity/status/72356243560126464...
Having option to run on a reasonably secure endpoint (e.g. the Copperhead's of this world), that users have some hope of securing, seems a pretty reasonable desire. Since increased security is really the only point of using Signal, and a secure channel is useless if the endpoint is not.
The name "LibreSignal" was also not the same as "Signal". If they HAD just redistributed as "Signal" (especially if trademarked), or otherwise didn't make clear it was an independent/unofficial build, then sure that's an issue. However the developers agreed immediately to changing the name further when requested.
In terms of the voice server, I'm just going on what other developers have stated. I'm not personally aware whether the TURN server is the only missing component or not.
The fact is though, if a user wants to run Signal on a straight-forward Android Open Source device, without adding a large attack surface of Google Apps, then Signal app is not an option. Regardless whether open source clones are possible, you know communications utility comes down to the network itself too (Metcalfe's Law) and holding one tin can, with a dangling piece of string and no one on the other end is rather useless. Now Signal has captured the whole user base, there's large costs in changing.
Anyway, your code, your call. I think the key thing, is that people were surprised. Closed distribution models and controlled ecosystems, coming from a company purporting itself as being Open (and not meaning to be personal, but by a guy calling himself an anarchist), was not what people thought they'd been promoting.
We don't think you're everything bad in the world. We just wish that using Signal was an option.
"You know full well that it's illegal to use systems without authorisation. In the US, it's called the Computer Fraud and Abuse Act and they'd be committing a criminal offense, with severe penalties, if they did (and government could prosecute with or without OWS consent, as AaronSw experienced). There's also an open ended civil claim you'd now have against them. So whether express or implied, the project from then on, was under a direct cloud of legal threat."
Wait what? Because what they did was illegal, to ask them to stop is to threaten legal action?
A: "Hey, you just hit me, can you stop?"
B: "Oh sorry we'll stop."
C: "Gosh, you didn't have threaten them with legal action!"
A: "What when did I do that"
C: "You know full well assault is a criminal offense and the government could prosecute with or without your consent. There's also an open ended civil claim you'd now have against them."
i.e. Don't pretend to be "Open", altruistic, acting only in users security interests, selling benefits of open source, taking public interest donations, contributions, etc - and then prevent users from actually exercising simple neighborly freedoms. It's not like LibreSignal were doing anything particularly different to Desktop. LibreSignal would have been thrilled to have just had it upstreamed anyway.
How many Signal users don't have GCM or Play Store? 1%? Hardly an extreme server load burden. More so, it would have attracted code contributions to further improve Signal. Equating THAT with assault as you have, is rather fkng melodramatic.
Oh, wait, people are taking liberties and entitlements? Well what the hell do you think you're doing by using the GPL in the first place? What was the spirit and intent of the authors who wrote it? Do you think THAT is being respected?
Quite simply, don't give people nasty lock-in surprises. If you intend to be a closed, tightly-controlled cathedral of non-optional dependencies on large swathes of commercial mystery meat blobs - then just say so in the first place. If you start off with non-commercial protocols like SMS, then switch to GCM, plus have federation clearly in your plan, until you're big enough you don't have to care and can rip it - then give people an out that doesn't involve losing their whole network.
Whether you like it or not, a big part of the reason Signal attained the critical mass of users necessary to take it to the next level, was the promotion and backing of the FOSS community.
The attack on open protocols, cooperation, standards and community is hence the most disappointing part. We wouldn't even be having this conversation, if we weren't here standing on the shoulders of giants of open protocols from IETF, W3C, etc. Signal's contribution was respected as one of those, until it transformed (or revealed?) itself as a closed monopoly.
I never equated anything with assault. I in fact presented using the term "assault" as being melodramatic and an overreaction, just like calling upon the Computer Fraud and Abuse Act in this case is being melodramatic and an overreaction, and which Moxie has never done.
Ahh okaay, hitting someone (as you put it) is not assault now?
Let's cut to the chase. Were they legally free to continue, or not? No. Were they at risk of Aaron Swartz style incarceration if the did? Possibly, since that community also includes among it public interest defenders, political dissidents, journalists, whistleblowers, etc. and we've seen it all before. 50 years imprisonment and $1 million for Aaron Swartz (for a download), a hellish trial he couldn't afford against Goliaths, or plee bargain guilty to a minimum 6 months imprisonment and lifetime exclusion from any political life (which he'd planned) - DESPITE MIT & JSTOR declining to proceed
Was LibreSignal technically doing something wrong in the first place? Debatable. I haven't read that part of Signal's ToS, but it had been implied to be an open community (and certainly they immediately ceased and desisted on request). Was it ethically wrong? Hardly "because what they did was illegal" as you put it, a major crime and DEFINITELY not the equivalent of hitting someone.
The implication that OWS had directly threatened explicit legal action, was too strongly stated and I'm happy to withdraw that (I had another case in mind). Nevertheless, the end result hasn't been all that different for practical purposes.
> i.e. Don't pretend to be "Open", altruistic, acting only in users security interests, selling benefits of open source, taking public interest donations, contributions, etc - and then prevent users from actually exercising simple neighborly freedoms.
What in the world do you think our motivation is, then? We're not a business, it's not like we're doing all of this to capture revenue. We could all be making orders of magnitude more working elsewhere. We're doing this because we believe it's the most effective way to make private communication ubiquitous, and it's working.
> How many Signal users don't have GCM or Play Store? 1%? Hardly an extreme server load burden. More so, it would have attracted code contributions to further improve Signal. Equating THAT with assault as you have, is rather fkng melodramatic.
What code contributions? If this is something you want to see in Signal, sure, submit a clean well-written PR and stick around to maintain it. The only contributions we've seen from this particular community haven't even begun to pass code review.
> Oh, wait, people are taking liberties and entitlements? Well what the hell do you think you're doing by using the GPL in the first place? What was the spirit and intent of the authors who wrote it? Do you think THAT is being respected?
Exactly, we make our code available under the GPL. That entitles you to use the code for whatever you would like under the terms of the license. It does not entitle you to use our service for your product, or to use our name for your product.
> Quite simply, don't give people nasty lock-in surprises. If you intend to be a closed, tightly-controlled cathedral of non-optional dependencies on large swathes of commercial mystery meat blobs - then just say so in the first place. If you start off with non-commercial protocols like SMS, then switch to GCM, plus have federation clearly in your plan, until you're big enough you don't have to care and can rip it - then give people an out that doesn't involve losing their whole network.
I think I've been pretty consistent in my position from the beginning. I've been saying the same things over and over at least since #127, which was early 2013. It's true that we wanted to pursue federation, and we did. But when we tried it with Cyanogen, it was a total nightmare that probably set us back a year in development time. So we've learned from our mistakes, which I think is a good thing. We'd all be better off if projects like XMPP had also learned from their mistakes.
> Whether you like it or not, a big part of the reason Signal attained the critical mass of users necessary to take it to the next level, was the promotion and backing of the FOSS community.
I don't know what you consider "the FOSS community," but I think of them as being the same people who have been sending me a torrent of verbal abuse, legal threats, and even death threats pretty much non-stop over the past three years. At no point have I wanted any part of that.
> The attack on open protocols, cooperation, standards and community is hence the most disappointing part. We wouldn't even be having this conversation, if we weren't here standing on the shoulders of giants of open protocols from IETF, W3C, etc. Signal's contribution was respected as one of those, until it transformed (or revealed?) itself as a closed monopoly.
Plenty of people have used the Signal source to build their own projects (some even in "the FOSS community" like SMSSecure), so I don't know how you can say it's closed. Plenty of other people have also come to our project with an understanding of our development goals, and have helped to contribute to making Signal something better. A very small vocal minority of FOSS moralists have decided that we should have to do whatever they want if they scream loudly enough, and have contributed very little of anything but verbal abuse.
I should clarify "The core issue with XMPP was that MSN Messenger, ICQ, etc. had deeper pockets.", is not precisely correct. The core issue is that they had a captive audience, continual popups and enormous barriers to entry against better technologies, allowing them to bully others out of the market. Another closed network.
> What in the world do you think our motivation is, then?
I didn't have much doubt before. But once you double-down on technical strategies that entrench concentrated power of Google, Apple, etc and leave users without open source options, I have to start to wonder.
> What code contributions?
I guess we'll never know. I think more could have been done to bring them back in though. There was obviously significant interest in LibreSignal for a reason and the community sure looked big enough to curate a PR between them. I'm pretty sure that the only reason they'd have given a different name to the fork (which might have evolved into a solid PR), was that they'd been told blanket that FDroid was never going to happen and hard Google dependencies would continue to be baked in.
> It does not entitle you to use our service for your product, or to use our name for your product.
Mate, you've been spending too much time with corporate lawyers. Take a breath. It's not a "product". In the days that GPL was written, operating as a closed service wasn't something the founders had even contemplated. It just wasn't the done thing.
> We'd all be better off if projects like XMPP had also learned from their mistakes.
The core issue with XMPP was that MSN Messenger, ICQ, etc. had deeper pockets. It wasn't fundamental technical flaws in open protocols. Sure, protocols don't always get it right the first time. I don't think HTTP would be better today though if we had to use 10 different browsers from 10 different vendors with pages that won't link together. Yes, XMPP had some issues (chief of which for mobile, was battery drain resolved by push). Let's hope Matrix gets traction.
> I don't know what you consider "the FOSS community," but I think of them as being the same people who have been sending me a torrent of verbal abuse, legal threats, and even death threats pretty much non-stop over the past three years. At no point have I wanted any part of that.
Well that's pretty sad. The BSD kernel of your iPhone, the Linux kernel of your Google devices and the GNU user space you enjoy on Linux are what the FOSS community have built. It just sounds like you're painting the whole community as abusive now.
Death threats etc should be reported to police. Likewise the community shouldn't be tolerating abuse. My condolences that you've had to go through that @moxie. It's bullshit and behaviours like that help no one.
No doubt, it's been traumatic and stressful, so I want to cut you a lot of slack. This in no way excuses their behaviour and I've never seen you engage in abuse, but mate (and recognising we're all human), your tone hasn't always come across as encouraging either.
> Plenty of people have used the Signal source to build their own projects (some even in "the FOSS community" like SMSSecure), so I don't know how you can say it's closed. Plenty of other people have also come to our project with an understanding of our development goals, and have helped to contribute to making Signal something better. A very small vocal minority of FOSS moralists have decided that we should have to do whatever they want if they scream loudly enough, and have contributed very little of anything but verbal abuse.
It sounds like it's always just going to be a protocol issue. Signal is a closed service and a closed network, unless you're using Signal's App. The GPL for the app in that context seems fairly meaningless in practical terms.
To anyone looking on, from the outside, it looks like OWS has taken a giant flip from their previous position: https://twitter.com/lyon01_david/status/733096322304249856. Maybe you need to work on your PR. When people see companies like Facebook given rights, but open source are not, it naturally raises eyebrows. Good on you for opening the iOS libraries now, but maybe it should just have been clearly stated (or repeated when necessary) that it was your intention all along, otherwise it really does give the impression it was only due to 'complaints'.
The fact that you keep painting other projects as "products" and legitimate security concerns as mere 'FOSS moralism', does make people really ponder what the development goals are.
> To anyone looking on, from the outside, it looks like OWS has taken a giant flip from their previous position:
This is not a "giant flip." We told Chris and everyone else both in person and publicly that they were free to use these libraries in their apps so long as they were otherwise complying with the GPL. You can even see my response to that exact comment here: https://news.ycombinator.com/item?id=11727870
Even though we had given explicit permission for Chris and others to use this code in their OSS apps, people like you -- who wish to see conspiracy in every choice we make -- continued to paint it as some kind of cold calculated move to prevent OSS apps from using our software (for what reason is beyond me). So we worked with a lawyer on this solution.
And now, what? This is part of the conspiracy too. Great.
> "I'm not OK with LibreSignal using our servers, and I'm not OK with LibreSignal using the name \"Signal.\" You're free to use our source code for whatever you would like under the terms of the license, but you're not entitled to use our name or the service that we run."
Yes, that is what I said, after they explicitly asked "Let's ask @moxie0 if he is OK with LibreSignal using OWS servers."
They asked, "are you OK with this," and I responded "I'm not OK with this." I never took any action at all, just gave them my opinion when they asked for it.
If you think it's reasonable to go around telling people that I "threatened legal action" to LibreSignal based on that exchange, I don't know how you expect me to take anything you say seriously.
Read down thread my reply to laughinghan. The implication you personally, explicitly threatened direct legal action (whether implied or not) is possibly too strongly stated and I'm willing to rephrase that.
Suggesting it was meerly stated as a preference though, is not how a reasonable person would read "you're not entitled to use" and "we are not letting other people use our name in their products".
Perhaps it wasn't your intent, but the implication was clear and additionally the law follows the letter first. They "were threatened legal action with if they did" and even if you didn't actually intend to open that risk to them from yourself (as it was understood), they were still after that, at threat from others.
Regarding entitlement, it's not just an advertising company the 'product' is tied to. Google is of course one of the most aggressive global profit-shifters for tax 'minimisation'. I would prefer to call it avoidance, as I can't see any other reason for it, but I don't have pockets deep enough for the legal defense to use a word like that (or evasion).
It's a little depressing Moxie believes federated protocols can't compete with unfederated/proprietary ones. I don't like the idea of all future innovation taking place in the Slacks and WhatsApps rather than the IRCs and SMTPs.
Are there any recent counter examples of successful federated protocols?
It would be an interesting thought experiment to design a protocol that started with the basic features of IRC and incrementally layered on new features in backwards compatible / gracefully degrading ways until you arrived at Slack. Of course it would be a lot easier with the benefit of hindsight than if you started in the 1980s.
It's all that and more. Not only does it have the basic features of XMPP+IRC (and others), but it also federates/bridges with those existing open standards! Plus supports WebRTC signalling and of course end-to-end 1:1 & group encryption (Olm/MegOlm).
There's a range of client, server and library options. Vector.IM (with web, iOS and Android clients) is a good place for many to start and you can try on an existing service. Then if you want, just fire up your own server and it'll federate with the rest.
If you only needed pure XMPP, Conversations.IM is superb too.
I think it seems clear that, in some circles, I have a number of unpopular opinions around federation, third party clients, app distribution, and what technologies are necessary or appropriate for large scale adoption of end to end encryption in today's world.
However, I'd be interested to hear more about why you think those unpopular opinions constitute "mistreatment." Am I guilty of something more than articulating my preferences and explaining our rationale for the decisions that we've made with our project?
It seems to me that your choice to open source the code without also saying "sure, we'll just give away everything else however people who want to use the open source want us to" is resulting in people falling into the Copenhagen Interpretation of Ethics trap ( https://blog.jaibot.com/the-copenhagen-interpretation-of-eth... ). Shortest quote that summarises the article's point: "There wouldn’t be any scathing editorials if BBH Labs had just chosen to do nothing – but they did something helpful-but-not-maximally-helpful, and thus are open to judgment."
Looking at the LibreSignal thread, you appear to be replying with the sort of snippy tone that I tend to end up using when I'm explaining the same damn thing for the Nth time to an audience that probably isn't going to listen. The only thing I've found that works for me to avoid ending up doing that is to summarise the explanation into (for IRC channels specifically) a factoid entry in an infobot or (for longer things and other distribution means) a blog post.
Or, alternatively, (1) people are being entitled as fuck because, well, people are people, (2) you might wish to consider writing up a blog post explaining the reasons for all of said opinions and then just post a link to it, since this will probably achieve just as much as trying to argue and will be far less bloody annoying for you, (3) IMO you're not guilty of anything and "carry on doing exactly how you're already doing" is not a choice I personally can see any good reason to fault you for.
(random free opinions of this HN commenter worth exactly what you paid, of course ;)
The GPL is an amazing license to gag developers while looking like a good person in the process. Not saying that is happening here but I have seen this before where questionable motivations where the driving force behind the license choice.
The GPL is an amazing license to prevent devs from profiting off others' work without also providing access to their own. Some might call that a "gag" because they're prevented from using the code without opening their own code as well, so it's closed to them for all practical purposes.
Is that the kind of gag that you're talking about, or did you mean something different?
> Is that the kind of gag that you're talking about, or did you mean something different?
I meant that the GPL as a license can be used to gag others while keeping a positive image as a person yourself. There are many licenses that can be used like this (the CDDL in particular was used for that purpose). That in itself has nothing to do with the GPL, more that you as a copyright holder have the ability to do things that are not available for others.
I don't understand what you mean by "gag" and "positive image".
The GPL is a very good license, because it has one benefit that almost all other licenses don't: it restricts use of your code to free software. If you care about software freedom, or want to live in a world where proprietary software is a thing of the past, then that should be reason enough to use it. Positive image is not a clause in the GPL, so I really don't know what you mean.
Not OP, but I think I get what they're trying to say.
The GPL requires others to follow its terms, because that's the only license of the code that's available to them. There is no clause of the GPL or any software license that I'm aware of that prevents you from doing whatever you want with your own code under different terms.
Therefore, you can do something negative (sell software that uses changes to GPL'd code without providing those sources to others when they ask for it), while maintaining a positive image ("look, I license my code under the GPL because I care about software freedom").
You can see this happening in practice with software that has a "community" edition available under the GPL, but a paid version that's not GPL'd. The holder of the copyright gets to profit off of other people's well meaning contributions (which almost certainly will have had their copyright assigned to the original copyright holder), but the people who contributed don't get the benefit of the copyright holder's changes to that code that are only available to paid customers.
You can argue that those contributors made their contributions knowing that would happen, but the fact that it is possible somewhat undermines the entire point of the free software movement.
Tangentially related, but since we're talking about Signal and have Moxie's attention ...
Does anybody know how the "privacy preserving contact discovery" works?
One of my unpleasant experiences with Signal was receiving a greeting from an unknown number when I installed it. Fortunately, it was a friend with a new number I hadn't known ... but the potential privacy leak - without any apparent warning, consent or opportunity to opt-out - bothered me.
Best info I could find is a blog basically saying "privacy preserving contact discovery is an unsolved problem" ... which is hardly reassuring:
I posted on the issue tracker and a few other places about this and was shut down. Apparently it's a support issue, not a technical one. From my (limited and potentially erroneous) understanding, Signal hashes each of your local contacts and uses that hash to query whether the number is registered with OWS. If so, you receive a notification to that effect. Essentially, you can identify Signal users without actually communicating with them. Though the same is true with PGP if you use a public keyserver.
That said, it gave some friends quite a fright. It's really unfortunate this wasn't opt-in or publicized before-hand.
Although we personally trusted and would've moved forward with Moxie's informal permission to distribute SignalProtocol within ChatSecure on the App Store, our funder required us to get the legal details squared away or we'd lose our funding. This announcement is an amazing gift for us, and for other GPL compatible Mac/iOS apps.
This announcement also more broadly benefits the copyleft community. There has been a decline in GPL apps on Apple platforms, particularly because of this conflict between the GPL and Apple's App Stores. It makes it clumsy to accept pull requests because you need a CLA to allow relicensing for distribution. There's a also lot of FUD from anti-Apple copyleft zealots. Having a good template for other developers who wish to stick to strong copyleft without worrying about App Store issues is a great contribution to the Apple-friendly copyleft community.