
License update - jboynyc
https://whispersystems.org/blog/license-update/
======
chrisballinger
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.

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

~~~
comex
Where does Google state that?

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.

[http://www.google.com/intl/en/policies/terms/](http://www.google.com/intl/en/policies/terms/)

== Random usage rules ==

Google:

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

Source:

Google: [https://play.google.com/about/play-
terms.html](https://play.google.com/about/play-terms.html)

Apple: [http://www.apple.com/legal/internet-
services/itunes/us/terms...](http://www.apple.com/legal/internet-
services/itunes/us/terms.html)

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

~~~
Natanael_L
Google Play ToS: [https://www.google.com/mobile/android/market-
tos.html](https://www.google.com/mobile/android/market-tos.html)

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

These in combination has the effect I described.

[https://play.google.com/intl/en_us/about/play-
terms.html](https://play.google.com/intl/en_us/about/play-terms.html)

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

Copyleft license is automatic authorization.

~~~
comex
> Google Play ToS: [https://www.google.com/mobile/android/market-
> tos.html](https://www.google.com/mobile/android/market-tos.html)

[..]

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

[https://www.android.com/market/terms.html](https://www.android.com/market/terms.html)

Plus, the Android Market ToS says ©2011 at the bottom. Combining those
indications, I think that despite being still up on www.google.com, it's
outdated and no longer in effect.

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.

------
geofft
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/](https://www.mozilla.org/en-US/MPL/2.0/))._

This seems less straightforward than what e.g. Mosh has.
[https://github.com/mobile-
shell/mosh/blob/master/COPYING.iOS](https://github.com/mobile-
shell/mosh/blob/master/COPYING.iOS)

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

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

~~~
geofft
One thing that makes me happy about the Mosh approach is that they got lawyers
(SFLC, specifically) to advise on exactly how to phrase it.

------
ge0rg
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...](https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165)

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

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

~~~
jsingleton
If the code is GPL then shouldn't WhatsApp need to be open source? Or did they
get a different license?

The only thing listed at
[https://www.whatsapp.com/android/](https://www.whatsapp.com/android/) are
some changes to qcom as per the LGPL.

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

~~~
dlmetcalf
Nope, WhatsApp were given a different license. Unlike ChatSecure, who until
this most recent change, were locked out from iOS.

~~~
dlmetcalf
It's good to see.

------
richard_mcp
This is probably partially in response to some of the issues that were
discussed here:
[https://github.com/LibreSignal/LibreSignal/issues/37](https://github.com/LibreSignal/LibreSignal/issues/37)

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

~~~
Arathorn
That thought experiment lives today in the form of Matrix.org :)

------
sigdoubt
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:

[https://whispersystems.org/blog/contact-
discovery/](https://whispersystems.org/blog/contact-discovery/)

What's the story?

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

------
lucb1e
The license file in the library linked from the blog post hasn't been changed
in 9 months. What am I missing?

[https://github.com/WhisperSystems/libsignal-
protocol-c/blob/...](https://github.com/WhisperSystems/libsignal-
protocol-c/blob/master/LICENSE)

