cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: [Android] Refactoring for different engines
Date Tue, 29 Apr 2014 18:22:52 GMT
On Tue, Apr 29, 2014 at 10:55 AM, Joe Bowser <bowserj@gmail.com> wrote:

> So, when Apache publishes something, it has fill the following criteria:
>
> - All source code must have their licence headers intact
> - All third-party source code must be mentioned in the NOTICE file
> - No Binary Blobs - No compiled libraries, which include JARs and
> shared object files (including the pak).
>
> Now, with Crosswalk, there's obviously the Chromium Library that we
> need, so we need a way to get that into the generated project somehow.
>  The easiest way is with plugman, but the issue is that Apache can't
> legally pass around binary blobs when it does an official release of
> anything.  Intel, OTOH, isn't restricted by cumbersome open source
> foundation rules, and can do so.
>

Intel has their own rules to follow, certainly, but we're presuming here
that Intel has already worked out the legal requirements to distribute
Crosswalk in the first place, so the idea of Intel also distributing the
"official" Crosswalk Cordova Engine plugin just seems to make a lot of
sense.

Apache distributes Cordova-Android, which defines the integration API, and
includes the default AndroidWebView classes, and other parties should be
free to distribute their own engine plugins, implementing that API. That
distribution can then be in any form that makes sense (and complies with
the licenses of the various components)

Joe's right that it would be awkward, if not impossible, for Apache to
distribute the Crosswalk core library. We'd have to include the 15GB of
source as well, at the very least, and that doesn't sound like fun at all.
It *is* all open-source, but there are a lot of different licenses in
there, and we'd need some lawyerly help to make sure that the ASF could
release software that included it all.

Ian


> On Tue, Apr 29, 2014 at 7:43 AM, Hu, Ningxin <ningxin.hu@intel.com> wrote:
> >> - who publishes the plugins, intel or cordova?
> >
> > For this open, could someone elaborate it a little bit more? What does
> it mean? I remembered someone mentioned the license is open in the
> hangouts, any details?
> >
> > Thanks,
> > -ningxin
> >
> >> -----Original Message-----
> >> From: mmocny@google.com [mailto:mmocny@google.com] On Behalf Of Michal
> >> Mocny
> >> Sent: Saturday, April 26, 2014 12:53 AM
> >> To: dev
> >> Subject: Re: [Android] Refactoring for different engines
> >>
> >> Notes:
> >>
> >> - native junit tests needs fixing (due to deprication)
> >>
> >> - common script for creating walk mobilespec
> >>
> >> - fix failing mobile spec tests (file-transfer?, media?)
> >>
> >> - who publishes the plugins, intel or cordova?
> >>
> >> - static vs dynamic xwalk lib
> >>
> >>   - (option) one plugin, use hooks to download static library
> >>
> >>   - (option) one plugin, just bundle static lib
> >>
> >>   - (option) one plugin, download static lib on app run
> >>
> >>   - (option) two plugins, xwalk lib bundled in a separate plugin, and
> can be added
> >> as a <dep>?
> >>
> >> - intel vs arm binary apk targets for CLI.  Two android platforms, or
> just two build
> >> targets?
> >>
> >> - How long to get GeckoView: Joe not sure. days to weeks :(
> >>
> >>   - Not blocking, though
> >>
> >> - plugman works to install but CLI does not, lets figure that out
> >>
> >> - Other platforms: Windows Phone support!?  BB10?!
> >>
> >> - Can we share code between xwalk WebViewClient and gecko view
> >> WebViewClient etc?
> >>
> >>
> >> On Fri, Apr 25, 2014 at 12:09 PM, Josh Soref <jsoref@blackberry.com>
> wrote:
> >>
> >> > Ian Clelland wrote:
> >> >
> >> > >
> >> >
> https://staging.talkgadget.google.com/hangouts/_/7ecpi3uaclcuedn7imn6b
> >> > 9jdq
> >> > >c
> >> >
> >> > https://talkgadget.google.com/hangouts/_/7ecpi3uaclcuedn7imn6b9jdqc
> >> >
> >> > Might work. Staging is probably internal.
> >> >
> >> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message