Live data from Hacker News

License update

whispersystems.org

11–20 of 71 posts

Re: License update

#11
Thank you Moxie!

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.

Re: License update

#12

This is probably partially in response to some of the issues that were discussed here: https://github.com/LibreSignal/LibreSignal/issues/37

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.

Re: License update

#13
post #10

Earlier quoted context omitted.

Moxie has always been a huge dick in this regard. I have no respect for Signal because of his mistreatment of the open source community.

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…

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 ;)

Re: License update

#14
post #8
post #4

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…

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.

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.)

Re: License update

#15

This is probably partially in response to some of the issues that were discussed here: https://github.com/LibreSignal/LibreSignal/issues/37

I think this blog post [0] is more of a direct response to the discussion in that thread.

[0] https://whispersystems.org/blog/the-ecosystem-is-moving/

Re: License update

#16
post #8
post #4

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…

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.

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.

Re: License update

#17
post #5

Please be aware that you may not use this code to interact with OWS servers or in an app containing "signal" in the name [0]. [0] https://github.com/LibreSignal/LibreSignal/issues/37#issueco...

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.

Re: License update

#18
post #10

Earlier quoted context omitted.

Moxie has always been a huge dick in this regard. I have no respect for Signal because of his mistreatment of the open source community.

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…

It's your code. Anyone who thinks differently can go pound sand.

In general I'd prefer to see security relate libraries LGPL licensed to encourage their widespread adoption.

Re: License update

#19
post #6

Earlier quoted context omitted.

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.

How does the GPL gag developers?

The GPL does not but it can be used as a vehicle that does.

Re: License update

#20
post #17
post #5

Please be aware that you may not use this code to interact with OWS servers or in an app containing "signal" in the name [0]. [0] https://github.com/LibreSignal/LibreSignal/issues/37#issueco...

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 cou…

> 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.

Post reply on HN