Incubator PMC report timeline for July 2019

[Justin Mclean]

Hi,

Here’s the timeline for the next incubator report [1]

Wed July 03 - Podling reports due by end of day 
Sun July 07 - Shepherd reviews due by end of day 
Sun July 07 - Summary due by end of day 
Tue July 09 - Mentor signoff due by end of day 
Wed July 10 - Report submitted to Board 
Wed July 17 - Board meeting 

Continuing on from last month and from this point on the report will be in 
markdown format.

Thanks,
Justin

1. https://cwiki.apache.org/confluence/display/INCUBATOR/July2019


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Druid (incubating) 0.15.0 [RC2]

[Gian Merlino]

> I'll leave that to others to decide, but if I were release manager, I
> would fix them before release.

Thanks for taking the time to inspect our release!

I'm not the release manager here, but my thoughts are that for issues such
as this, it makes sense to fix them for the next release rather than the
current one. The reason is just that the cycle time is quite long for
cutting RCs (72 hour vote on the project list + 72 hour vote on the
Incubator list, the latter of which often takes longer than 72 hours due to
IPMC folks being a busy bunch).

On Fri, Jun 21, 2019 at 3:02 AM sebb  wrote:

> On Fri, 21 Jun 2019 at 02:12, Jihoon Son  wrote:
> >
> > Thank you for your detailed review!
> >
> > We will address your comments on signing keys in the future votes.
> >
> > Regarding the commit id, "44c9323" is the correct commit id for the tag.
> > Maybe the link is not valid.
> > Is https://github.com/apache/incubator-druid/commits/44c9323 or
> >
> https://github.com/apache/incubator-druid/tree/druid-0.15.0-incubating-rc2
> more
> > valid one?
>
> The first one is immutable but not obvious, the second is not
> guaranteed immutable.
>
> However you could use:
>
> https://github.com/apache/incubator-druid/tree/druid-0.15.0-incubating-rc2
> (44c9323
> 
> )
>
> > Finally, would you elaborate more on what looks wrong to you in NOTICE
> and
> > NOTICE.BINARY files?
>
> NOTICE files should contain only what is strictly required for the
> files actually contained in the bundle to which they apply.
> See:
> [1]
> http://www.apache.org/dev/licensing-howto.html#assembling-license-and-notice
>
> The header looks OK, but most of the rest looks unnecessary.
>
> No need to mention Apache Licensed code unless the bit you have copied
> has a required notice in its NOTICE file.
>
> In the case of the other products, they may or may not require entries
> in NOTICE.
> That depends on their license.
> As per [1], generally BSD and MIT code does not require an entry in NOTICE.
>
> The last section (JetS3t) does not make sense.
>
> Similar considerations apply to NOTICE.BINARY
> In the case of commons-codec-1.7.jar, does the binary bundle actually
> include the file
> DoubleMetaphoneTest ? It seems unlikely -- if not present, the entry
> is not required.
>
> The LICENSE file likewise is generally OK (assuming it corresponds
> with the software that is in the source bundle). It's good that the
> software versions are mentioned. However the license pointer is
> missing for the Porter Stemmer. It can be guessed from the previous
> entry, so that is not a blocker.
>
> > We will fix them if necessary for this release.
>
> I'll leave that to others to decide, but if I were release manager, I
> would fix them before release.
>
> > Jihoon
> >
> > On Thu, Jun 20, 2019 at 9:46 AM sebb  wrote:
> >
> > > On Thu, 20 Jun 2019 at 03:39, Jihoon Son  wrote:
> > > >
> > > > Hi IPMC,
> > > >
> > > > The Apache Druid community has voted on and approved a proposal to
> > > release
> > > > Apache Druid (incubating) 0.15.0 (rc2).
> > > >
> > > > We now kindly request the Incubator PMC members review and vote on
> this
> > > > incubator release.
> > > >
> > > > Apache Druid (incubating) is a high performance analytics data store
> for
> > > > event-driven data.
> > > >
> > > > The community voting thread can be found here:
> > > >
> > >
> https://lists.apache.org/thread.html/f4b1b708bcb7e6ec08e6a9cfcb2c0dfcb565fab353ccbb8c5f362218@%3Cdev.druid.apache.org%3E
> > > >
> > > > The release notes are available here:
> > > > https://github.com/apache/incubator-druid/issues/7854
> > > >
> > > > The release candidate has been tagged in GitHub as
> > > > druid-0.15.0-incubating-rc2 (44c9323), available here:
> > > >
> > >
> https://github.com/apache/incubator-druid/releases/tag/druid-0.15.0-incubating-rc2
> > >
> > > I'm not sure that's the correct URL for the tag; it points to a couple
> > > of archives.
> > >
> > > I would expect a pointer to the source code.
> > > This should use the commit id that corresponds to the release
> > > candidate tag, i.e. the commit id that corresponds to
> > >
> https://github.com/apache/incubator-druid/tree/druid-0.15.0-incubating-rc2
> > > AIUI only commit ids are truly immutable
> > >
> > > The NOTICE and NOTICE.BINARY files look wrong to me; they have a lot
> > > of superfluous text.
> > >
> > > > The artifacts to be voted on are located here:
> > > >
> > >
> https://dist.apache.org/repos/dist/dev/incubator/druid/0.15.0-incubating-rc2/
> > > >
> > > > A staged Maven repository is available for review at:
> > > >
> https://repository.apache.org/content/repositories/orgapachedruid-1007/
> > > >
> > > > Release artifacts are signed with the key [95574000]:
> > > > https://people.apache.org/keys/committer/jihoonson.asc
> > > >
> > > > This key and the key of other committers can also be found in the
> > > project's
> > > > KEYS file here:
> > > > 

Re: [VOTE] Release Apache Druid (incubating) 0.15.0 [RC2]

[Jihoon Son]

Thanks! Your comment is really helpful.

I raised two PRs as below:

- https://github.com/apache/incubator-druid/pull/7941
- https://github.com/apache/incubator-druid/pull/7945

I will backport them to 0.15.0-incubating as well if it turns out to be a
release blocker.

Jihoon

On Fri, Jun 21, 2019 at 3:02 AM sebb  wrote:

> On Fri, 21 Jun 2019 at 02:12, Jihoon Son  wrote:
> >
> > Thank you for your detailed review!
> >
> > We will address your comments on signing keys in the future votes.
> >
> > Regarding the commit id, "44c9323" is the correct commit id for the tag.
> > Maybe the link is not valid.
> > Is https://github.com/apache/incubator-druid/commits/44c9323 or
> >
> https://github.com/apache/incubator-druid/tree/druid-0.15.0-incubating-rc2
> more
> > valid one?
>
> The first one is immutable but not obvious, the second is not
> guaranteed immutable.
>
> However you could use:
>
> https://github.com/apache/incubator-druid/tree/druid-0.15.0-incubating-rc2
> (44c9323
> 
> )
>
> > Finally, would you elaborate more on what looks wrong to you in NOTICE
> and
> > NOTICE.BINARY files?
>
> NOTICE files should contain only what is strictly required for the
> files actually contained in the bundle to which they apply.
> See:
> [1]
> http://www.apache.org/dev/licensing-howto.html#assembling-license-and-notice
>
> The header looks OK, but most of the rest looks unnecessary.
>
> No need to mention Apache Licensed code unless the bit you have copied
> has a required notice in its NOTICE file.
>
> In the case of the other products, they may or may not require entries
> in NOTICE.
> That depends on their license.
> As per [1], generally BSD and MIT code does not require an entry in NOTICE.
>
> The last section (JetS3t) does not make sense.
>
> Similar considerations apply to NOTICE.BINARY
> In the case of commons-codec-1.7.jar, does the binary bundle actually
> include the file
> DoubleMetaphoneTest ? It seems unlikely -- if not present, the entry
> is not required.
>
> The LICENSE file likewise is generally OK (assuming it corresponds
> with the software that is in the source bundle). It's good that the
> software versions are mentioned. However the license pointer is
> missing for the Porter Stemmer. It can be guessed from the previous
> entry, so that is not a blocker.
>
> > We will fix them if necessary for this release.
>
> I'll leave that to others to decide, but if I were release manager, I
> would fix them before release.
>
> > Jihoon
> >
> > On Thu, Jun 20, 2019 at 9:46 AM sebb  wrote:
> >
> > > On Thu, 20 Jun 2019 at 03:39, Jihoon Son  wrote:
> > > >
> > > > Hi IPMC,
> > > >
> > > > The Apache Druid community has voted on and approved a proposal to
> > > release
> > > > Apache Druid (incubating) 0.15.0 (rc2).
> > > >
> > > > We now kindly request the Incubator PMC members review and vote on
> this
> > > > incubator release.
> > > >
> > > > Apache Druid (incubating) is a high performance analytics data store
> for
> > > > event-driven data.
> > > >
> > > > The community voting thread can be found here:
> > > >
> > >
> https://lists.apache.org/thread.html/f4b1b708bcb7e6ec08e6a9cfcb2c0dfcb565fab353ccbb8c5f362218@%3Cdev.druid.apache.org%3E
> > > >
> > > > The release notes are available here:
> > > > https://github.com/apache/incubator-druid/issues/7854
> > > >
> > > > The release candidate has been tagged in GitHub as
> > > > druid-0.15.0-incubating-rc2 (44c9323), available here:
> > > >
> > >
> https://github.com/apache/incubator-druid/releases/tag/druid-0.15.0-incubating-rc2
> > >
> > > I'm not sure that's the correct URL for the tag; it points to a couple
> > > of archives.
> > >
> > > I would expect a pointer to the source code.
> > > This should use the commit id that corresponds to the release
> > > candidate tag, i.e. the commit id that corresponds to
> > >
> https://github.com/apache/incubator-druid/tree/druid-0.15.0-incubating-rc2
> > > AIUI only commit ids are truly immutable
> > >
> > > The NOTICE and NOTICE.BINARY files look wrong to me; they have a lot
> > > of superfluous text.
> > >
> > > > The artifacts to be voted on are located here:
> > > >
> > >
> https://dist.apache.org/repos/dist/dev/incubator/druid/0.15.0-incubating-rc2/
> > > >
> > > > A staged Maven repository is available for review at:
> > > >
> https://repository.apache.org/content/repositories/orgapachedruid-1007/
> > > >
> > > > Release artifacts are signed with the key [95574000]:
> > > > https://people.apache.org/keys/committer/jihoonson.asc
> > > >
> > > > This key and the key of other committers can also be found in the
> > > project's
> > > > KEYS file here:
> > > > https://dist.apache.org/repos/dist/release/incubator/druid/KEYS
> > > >
> > > > As part of the validation process, the release artifacts can be
> generated
> > > > from source by running:
> > > > mvn clean install -Papache-release,dist
> > > >
> > > > The RAT license check can be 

Re: No access to dist.apache.org

[leerho]

1) I asked INFRA how to setup the proper structures in dist.a.o.
INFRA tells me that IPMC members create the proper folders in dist/dev and
dist/release directories and once created the PPMC should have access.

2) There is also no "Staging Profile" in Apache Nexus Repository for
datasketches.  When does that get set up?



I have been held up for a full week now in making any progress in migrating
to ASF.  I need to create the first Release Candidate artifact so that it
can be referenced as a dependency by our other repositories.  I keep
running into roadblocks where the basic infrastructure has not be set up
that would allow me to make progress.

I would be really grateful if someone could help guide me through this
first "release" process steps.

Specifically:
a) Review our POM file for correct setup for a release to Apache (at least
a release candidate)
b) Guide me through the required Maven or command-line commands to get this
first release created.

Thank you!







On Fri, Jun 21, 2019 at 11:08 AM leerho  wrote:

> 1) I am trying to create our first podling release candidate and need
> access to dist.apache.org to record PGP keys, etc.  There is no listing
> for our podling project datasketches and I have no write access to that
> site.  How can I make progress?
>
> 2) I would like to create a temporary landing page for our website at
> datasketches.apache.org.
> How do I do that?
>
> Lee.
>

No access to dist.apache.org

[leerho]

1) I am trying to create our first podling release candidate and need
access to dist.apache.org to record PGP keys, etc.  There is no listing for
our podling project datasketches and I have no write access to that site.
How can I make progress?

2) I would like to create a temporary landing page for our website at
datasketches.apache.org.
How do I do that?

Lee.

Re: Podlings, the Incubator, relationships and Apache

[Alex Harui]

It all makes sense to me.  I think there are two key points that are driving 
all of this discussion:

"5. Disclaimers generally don't remove liability"

IANAL so I don't know if that's true or not.  For sure there are lots of 
disclaimers in the world.  I do not know the history of the current DISCLAIMER 
(and labeling of releases with -incubating).  What was the DISCLAIMERs original 
purpose?  Should it be modified to cover less-than-perfect podling releases, 
especially around CatX inclusions?  Who gets to make that call?

" It's not perfect compliance vs. failure.
IMO, the IPMC has been delegated the decision making process, and may
often find themselves making the business decision that an imperfect
release is better than a community stalled for months or years. Don't
let the perfect be the enemy of the good."

I think several "prominent" ASF members are saying this same thing, but nobody 
really wants to make it official.  The responsibility seems to have been passed 
around between IPMC, Board, and VP Legal.  How can the ASF get closure on this 
topic?

My 2 cents,
-Alex

On 6/20/19, 10:04 AM, "David Nalley"  wrote:

There's been a lot of discussion in various threads about bureaucracy,
whether podlings are part of the ASF, etc. As a result of that I've
spent a good deal of time reading resolutions and older discussions
and organizing those thoughts from a legal and community perspective.
I've also read a number of conversations from the more august members
of our body about this subject. Altogether it has somewhat changed
some of my opinions and assumptions. I've also sensed that there is a
community/business/legal disconnect in our conversations. We're using
the same words to mean very different things in each of those
contexts. That said I am but one member of the IPMC, but maybe this
will be helpful to someone else - I've tried to avoid my assumptions
in this.

The IPMC's first 'job'[1] is "accepting new products into the
Foundation" The second 'job' of the IPMC is to "provide guidance and
support to ensure that the Incubator's sub-projects[2] develop
products according to the Foundation's philosophy and guidelines". The
final 'job' is evaluating the products and determining whether they
should be abandoned, continue to receive guidance and support, or be
promoted to "full project status".

So there are several realizations I gained from this from the
Incubator perspective.
1. Acceptance into the Incubator is acceptance of the product into the
Foundation.
2. That product is then a sub-project of the Incubator.
3. The IPMC has the "primary responsibility for the management of
those subprojects".

From the Foundation's perspective there are a number of things that
come to mind:
1. We aren't a github/sourceforge/google code type platform where
random people can upload/post what they want.
2. We do not have DMCA Safe Harbor protection - e.g. we are
responsible for everything that we publish or distribute. With the
exception of wikis and bug trackers anyone who can put something up on
an Apache property has some form of legal relationship with the
Foundation. This could be as simple as an ICLAs where you've
contractually said you won't contribute anything you don't have rights
to.
3. Most of the project's who have come to us aren't entities in and of
themselves. E.g. the 'project' doesn't truly exist from a legal entity
perspective - and even those who do are at best an unincorporated
association of individuals. From a legal perspective - projects can't
make or distribute a release - they don't exist - only the ASF and the
individual(s) doing the work. Given that one of the explicit reasons
the Foundation was created was to[5]: "provide a means for individual
volunteers to be sheltered from legal suits"; we want them to create
and distribute releases as the Foundation.
4. Whether we like it or not - the Foundation is judged on the output
from our projects and subprojects. We have a reputation of having
clean IP, permissively licensed open source code, with clear
provenance. Many people explicitly copy our standards, guidelines, and
policies because they are the gold standard for good open source
governance.
5. Disclaimers generally don't remove liability, and even if they did,
our disclaimer talks about the maturity of our projects. - And it
certainly doesn't remove the public's expectations from us - frankly -
losing the publics trust is as scary as the potential legal liability.
6. The Board has delegated the responsibility of managing and ensuring
adherence to policies and guidelines to the IPMC. I don't see this
responsibility as boolean. It's not perfect compliance vs. failure.
IMO, the IPMC has been delegated the decision making 

Re: [VOTE] Release Apache Druid (incubating) 0.15.0 [RC2]

[sebb]

On Fri, 21 Jun 2019 at 02:12, Jihoon Son  wrote:
>
> Thank you for your detailed review!
>
> We will address your comments on signing keys in the future votes.
>
> Regarding the commit id, "44c9323" is the correct commit id for the tag.
> Maybe the link is not valid.
> Is https://github.com/apache/incubator-druid/commits/44c9323 or
> https://github.com/apache/incubator-druid/tree/druid-0.15.0-incubating-rc2 
> more
> valid one?

The first one is immutable but not obvious, the second is not
guaranteed immutable.

However you could use:

https://github.com/apache/incubator-druid/tree/druid-0.15.0-incubating-rc2
(44c9323)

> Finally, would you elaborate more on what looks wrong to you in NOTICE and
> NOTICE.BINARY files?

NOTICE files should contain only what is strictly required for the
files actually contained in the bundle to which they apply.
See:
[1]  
http://www.apache.org/dev/licensing-howto.html#assembling-license-and-notice

The header looks OK, but most of the rest looks unnecessary.

No need to mention Apache Licensed code unless the bit you have copied
has a required notice in its NOTICE file.

In the case of the other products, they may or may not require entries
in NOTICE.
That depends on their license.
As per [1], generally BSD and MIT code does not require an entry in NOTICE.

The last section (JetS3t) does not make sense.

Similar considerations apply to NOTICE.BINARY
In the case of commons-codec-1.7.jar, does the binary bundle actually
include the file
DoubleMetaphoneTest ? It seems unlikely -- if not present, the entry
is not required.

The LICENSE file likewise is generally OK (assuming it corresponds
with the software that is in the source bundle). It's good that the
software versions are mentioned. However the license pointer is
missing for the Porter Stemmer. It can be guessed from the previous
entry, so that is not a blocker.

> We will fix them if necessary for this release.

I'll leave that to others to decide, but if I were release manager, I
would fix them before release.

> Jihoon
>
> On Thu, Jun 20, 2019 at 9:46 AM sebb  wrote:
>
> > On Thu, 20 Jun 2019 at 03:39, Jihoon Son  wrote:
> > >
> > > Hi IPMC,
> > >
> > > The Apache Druid community has voted on and approved a proposal to
> > release
> > > Apache Druid (incubating) 0.15.0 (rc2).
> > >
> > > We now kindly request the Incubator PMC members review and vote on this
> > > incubator release.
> > >
> > > Apache Druid (incubating) is a high performance analytics data store for
> > > event-driven data.
> > >
> > > The community voting thread can be found here:
> > >
> > https://lists.apache.org/thread.html/f4b1b708bcb7e6ec08e6a9cfcb2c0dfcb565fab353ccbb8c5f362218@%3Cdev.druid.apache.org%3E
> > >
> > > The release notes are available here:
> > > https://github.com/apache/incubator-druid/issues/7854
> > >
> > > The release candidate has been tagged in GitHub as
> > > druid-0.15.0-incubating-rc2 (44c9323), available here:
> > >
> > https://github.com/apache/incubator-druid/releases/tag/druid-0.15.0-incubating-rc2
> >
> > I'm not sure that's the correct URL for the tag; it points to a couple
> > of archives.
> >
> > I would expect a pointer to the source code.
> > This should use the commit id that corresponds to the release
> > candidate tag, i.e. the commit id that corresponds to
> > https://github.com/apache/incubator-druid/tree/druid-0.15.0-incubating-rc2
> > AIUI only commit ids are truly immutable
> >
> > The NOTICE and NOTICE.BINARY files look wrong to me; they have a lot
> > of superfluous text.
> >
> > > The artifacts to be voted on are located here:
> > >
> > https://dist.apache.org/repos/dist/dev/incubator/druid/0.15.0-incubating-rc2/
> > >
> > > A staged Maven repository is available for review at:
> > > https://repository.apache.org/content/repositories/orgapachedruid-1007/
> > >
> > > Release artifacts are signed with the key [95574000]:
> > > https://people.apache.org/keys/committer/jihoonson.asc
> > >
> > > This key and the key of other committers can also be found in the
> > project's
> > > KEYS file here:
> > > https://dist.apache.org/repos/dist/release/incubator/druid/KEYS
> > >
> > > As part of the validation process, the release artifacts can be generated
> > > from source by running:
> > > mvn clean install -Papache-release,dist
> > >
> > > The RAT license check can be run from source by:
> > > mvn apache-rat:check -Prat
> > >
> > > This vote will be open for at least 72 hours. The vote will pass if a
> > > majority of at least three +1 IPMC votes are cast.
> > >
> > > [ ] +1 Release this package as Apache Druid (incubating) 0.15.0
> > > [ ]  0 I don't feel strongly about it, but I'm okay with the release
> > > [ ] -1 Do not release this package because...
> > >
> > > Thank you IPMC! We appreciate your efforts in helping the Apache Druid
> > > community to validate this release.
> > >
> > > On behalf of the Apache Druid PPMC,
> > > Jihoon
> > >
> > > Apache Druid (incubating) is an effort undergoing incubation at 

Re: LGPL dependency

[申远]

Sorry for my late reply, I have open a JIRA issue[1] for this problem.

I'm really appreciated your help here, thank you all.

[1] https://issues.apache.org/jira/browse/LEGAL-464

Best Regards,
YorkShen

申远


申远  于2019年6月18日周二 下午8:08写道：

> Thanks for help.
>
> I will bring this to legal-jira this weeks later.
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> Myrle Krantz  于2019年6月17日周一 下午8:07写道：
>
>> Thank you all,
>>
>> YorkShen, I think at this point the best thing to do is to open a "legal"
>> ticket at this Jira (https://issues.apache.org/jira/browse/LEGAL).  I
>> suspect that if you're only including the BSD-licensed headers, that Weex
>> will only be dependent on BSD-licensed code.  It's possible that the
>> "runtime" argument will work in this case too.
>>
>> But this discussion hasn't made me feel confident in either statement, and
>> there are other Apache projects for which this question may be relevant.
>> I'd like a final answer and the legal committee can provide that.
>>
>> Let me know if you need help formulating the ticket.
>>
>> Best Regards,
>> Myrle
>>
>> On Fri, Jun 14, 2019 at 7:13 PM Alex Harui 
>> wrote:
>>
>> > Some  things I don't think have been mentioned in this thread so far:
>> >
>> > 1) Even if you make Webkit optional by offering V8, I believe the ASF
>> > criteria for "optional" includes "less than half of your users will use
>> > that option" and so if Webkit offers better performance and most of the
>> > users select Webkit over V8, it won't really qualify Webkit as optional.
>> > 2) AIUI, the ASF does not care about the licensing of RUNTIMES (my
>> > emphasis) your project's code runs on.  Otherwise, no ASF project could
>> run
>> > on Windows or OSX.  Apache Flex runs on Adobe Flash/AIR runtimes.
>> > 3) I could not quickly find a direct quote for this, but I believe the
>> ASF
>> > does not care about the licensing of BUILD TOOLS (emphasis mine) used to
>> > manipulate the source in the source release as long as the license of
>> those
>> > tools does not constrain usage of that code (like some non-commercial
>> > restriction, or even a "no evil" restriction.
>> >
>> > AIUI, the whole purpose of these restrictions is to not place
>> restrictions
>> > on modifications to source or use of source when that source is
>> eventually
>> > executed (whether interpreted or compiled or other).
>> >
>> > So, if I've made that clear so far, the question I have for Weex is:
>> How
>> > is Webkit used in Weex?  Is it just a runtime and libraries for that
>> > runtime?  If so, then I believe it is ok to have a dependency on LGPL
>> > Webkit, but I would recommend that you find a way to not bundle Webkit
>> in
>> > the release artifacts.  Have it downloaded or make it a "prerequisite"
>> just
>> > like I think every ASF Java-based project says you must install a Java
>> JDK
>> > and don't bundle Java JDKs.
>> >
>> > Other questions to ask relative to whether Webkit is a runtime or build
>> > tool:
>> >
>> > A) Will anybody realistically want to modify the Webkit sources in order
>> > to use Weex?  If no, that's great, and another reason to not bundle
>> those
>> > header files with your sources.
>> > B) Will use of the WebKit header files and other binaries you depend on
>> > create a restriction on use?  If no, that's great as well, and I think
>> if
>> > the answer to A and B are both "no", the IPMC should consider Webkit to
>> be
>> > a runtime/build-tool dependency and let it go.
>> >
>> > HTH,
>> > -Alex
>> >
>> >
>> > On 6/14/19, 5:09 AM, "York Shen"  wrote:
>> >
>> > It depends on the definition of optional dependency. Weex targets
>> iOS,
>> > Android and Browser environment and Webkit header files and shared
>> library
>> > are only bundled for Android environment. As for other environments,
>> the OS
>> > or browser itself has exposed enough API for Weex.
>> >
>> > PS: I am pretty sure that the iOS system itself uses almost the same
>> > code of Webkit as Weex does to build its WKWebView. It’s really strange
>> > that’s ok for Weex iOS and not ok for Weex Android.
>> >
>> > > 在 2019年6月14日，19:17，Justin Mclean  写道：
>> > >
>> > > Hi,
>> > >
>> > >> Well, what if Weex copies some BSD header files in Webkit then
>> run
>> > on Webkit? IMHO, the Webkit is also an environment for Weex in this
>> case.
>> > >
>> > > You still didi not answer if this is an optional dependancy? But
>> > again either way I suggest you ask on legal discuss.
>> > >
>> > > Thanks,
>> > > Justin
>> > >
>> > >
>> > >
>> > >
>> -
>> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> > > For additional commands, e-mail:
>> general-h...@incubator.apache.org
>> > >
>> >
>> >
>> >
>>  -
>> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> > For additional