[email] Gaia licensing; is it okay to use LGPL 2.1 code in Gaia? (OpenPGP.js)

[Andrew Sutherland]

Mozilla's general licensing policy is at
http://www.mozilla.org/MPL/license-policy.html

Do we have any more restrictive policies or desires in place for Gaia
like strongly favoring Apache 2 licensed dependencies?

Specifically, there is community interest in prototyping PGP support for
the Gaia e-mail app. There is an existing library, OpenPGP.js
(http://openpgpjs.org/, https://github.com/openpgpjs/openpgpjs) that is
licensed under LGPL 2.1
(https://github.com/openpgpjs/openpgpjs/blob/master/LICENSE). Is this
something we can use?


The specific structuring is/would be like so:

- The e-mail app currently uses the gaia-email-libs-and-more library aka
GELAM for its backend
(https://github.com/mozilla-b2g/gaia-email-libs-and-more).

- Dependencies are currently pulled in via git submodules, in the future
we are leaning towards using npm where possible
(https://bugzilla.mozilla.org/show_bug.cgi?id=885048). Dependencies may
undergo a transformation build step to wrap them into AMD modules using
volo (https://github.com/volojs/volo) if they are not already AMD or UMD
(https://github.com/umdjs/umd) friendly.

- openpgp.js would accordingly be pulled in as a git submodule or an npm
dependency via git reference.

- Currently, GELAM is built into a series of concatenated/minified-ish
JS files that are checked into the gaia tree under apps/email/js/ext/.
This would include openpgp.js, although for licensing clarity we might
keep openpgp.js in its own separate JS file. In the future we are
leaning towards using something more npm-like
(https://bugzilla.mozilla.org/show_bug.cgi?id=885046 although there are
many potential issues/complications) which would avoid checking any code
into gaia other than the explicit dependency information.


Greater context: https://bugzilla.mozilla.org/show_bug.cgi?id=894817 is
the meta/discussion bug for all things involving supporting PGP and
S/MIME encryption and signatures. As discussed on the bug, PGP and
S/MIME are actually very different, but the issues are similar enough
that I think it's better to avoid fragmenting the discussion over
multiple bugs until implementation actually starts.

Thanks,
Andrew

[Andreas Gal]

At this time I would prefer to not depend on LGPL libraries. WebCrypto
might implement much of OpenPGP.js I think, so that route might be more
efficient (and secure) anyway.

Andreas

> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia

[Andrew Sutherland]

On 08/25/2013 01:42 AM, Andreas Gal wrote:
> At this time I would prefer to not depend on LGPL libraries. WebCrypto
> might implement much of OpenPGP.js I think, so that route might be
> more efficient (and secure) anyway.

Noted on the LGPL front. Thanks for the quick response!

WebCrypto-wise, yes, timing channel attacks against JS implementations
of crypto are terrifying, so we would never check pure JS crypto
implementations into the tree or make releases that we encourage people
to use. Gecko's WebCrypto implementation
(https://bugzilla.mozilla.org/show_bug.cgi?id=865789) is not yet
imminent, although the spec is planned to hit last call this October
(http://www.w3.org/2012/webcrypto/#sched) so it wouldn't surprise me if
the implementation lands this fall. But for any prototyping before that
time I think would need to use a pure JS implementation, possibly using
the partial polyfill at https://github.com/polycrypt/polycrypt or maybe
just using existing libs.

Andrew

[Andreas Gal]

Yeah, use the polyfill and we should get an ETA for the real implementation.

Andreas

Sent from Mobile.

On Aug 25, 2013, at 15:05, Andrew Sutherland