Re: Podlings, the Incubator, relationships and Apache

[Greg Stein]

On Wed, Jul 3, 2019 at 12:10 AM Justin Mclean 
wrote:
>...

> Hi,
>
> > Although not a "real" PMC, we do need to provide legal protection for
> each PPMC and distributing releases is the time that most legal
> considerations "kick in" as it were. So we need a


Or we *don't* provide legal protections. That *is* what the disclaimer is
there for.

>...

> Which while I don’t disagree with, again I ask how can a PMC (i.e the
> incubator) make releases that are not in line with policy? Current advice
> seems that the board would not grant a blanket exception like to the IPMC


I don't recall that advice. In fact, Roman seemed to indicate Legal would
be just fine with that.

IMO, stop being pessimistic. Move forward with change to stop the gating,
and let podlings do their releases without all the IPMC burden.

>...

> > Let's also recall that the origin genesis of the Incubator was NOT to
> provide legal oversight
>
> That may be the original thought, but historical threads bring up legal
> oversight very very early on. (I posted one from 2004 the other day).
> Hopefully someone can explain this history?
>

Who cares? Red herring. We are where we are. Move forward from here.

-g

Re: Podlings, the Incubator, relationships and Apache

[Justin Mclean]

Hi,

> Although not a "real" PMC, we do need to provide legal protection for each 
> PPMC and distributing releases is the time that most legal considerations 
> "kick in" as it were. So we need a clear "paper trail" of approvals for that 
> PPMC to enjoy the legal protection the foundation exists to provide. The IPMC 
> vote, since the IPMC is, in fact, a true PMC, provides that legal provenance 
> such that, should anything untoward happen, we can clearly show to outside 
> legal entities corporate provenance without having to try to explain the 
> intricacies of podlings, and PPMCs and PMC and et.al. :-)

Which while I don’t disagree with, again I ask how can a PMC (i.e the 
incubator) make releases that are not in line with policy? Current advice seems 
that the board would not grant a blanket exception like to the IPMC and we 
couldn't get consensus on submitting such a request to the board last month. So 
is it just a mater of refining that board proposal or is it a matter of 
changing the remit of the IPMC to make it clearer or even changing that the 
IPMC it is a TLP?
 
> Let's also recall that the origin genesis of the Incubator was NOT to provide 
> legal oversight

That may be the original thought, but historical threads bring up legal 
oversight very very early on. (I posted one from 2004 the other day). Hopefully 
someone can explain this history?

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

Re: Podlings, the Incubator, relationships and Apache

[Justin Mclean]

Hi,

> Jim said "Let's also recall that the origin genesis of the Incubator was NOT 
> to provide legal oversight, but rather education and guidance into The Apache 
> Way”

If you look at the history threads I posted the other day one was about “legal 
oversight” way back in 2004.

Thanks,
Justin




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

Re: Podlings, the Incubator, relationships and Apache

[Dave Fisher]

All we need is a simple pivot back. This is the closest, easiest path. 
Prioritize and ease the acceptance of the Apache Way.

Our current Disclaimer is enough. If governing in the way then the path to a 
PMC is eased.

We need to assure that the lessons from all versions of the Incubator are 
considered. I’ve attempted to resurrect the Clutch.

Warm Regards,
Dave

Sent from my iPhone

> On Jul 2, 2019, at 9:29 PM, Ross Gardler  wrote:
> 
> Jim said "Let's also recall that the origin genesis of the Incubator was NOT 
> to provide legal oversight, but rather education and guidance into The Apache 
> Way"
> 
> I say... HEAR! HEAR!
> 
> Get Outlook for Android
> 
> 
> From: Jim Jagielski 
> Sent: Tuesday, July 2, 2019 4:36:02 AM
> To: Incubator General
> Subject: Re: Podlings, the Incubator, relationships and Apache
> 
> 
> 
>> On Jul 1, 2019, at 1:45 AM, Alex Harui  wrote:
>> 
>> FWIW, I reconcile it as:
>> 
>> Incubator is a PMC and must record a business decision to call something an 
>> ASF release in order to place that release under the legal protection of the 
>> ASF.  ASF releases may have policy non-compliance issues.  No TLP can decide 
>> on its own to never comply with policy.  But the business decision of the 
>> costs of delaying a release to correct non-compliance vs risks of 
>> distributing a release with any non-compliance is up to the TLP.  VP Legal 
>> will assert a risk profile for any non-compliance and VP Legal or any ASF 
>> Member or PMC Member should try to stop a release if a TLP decides to 
>> distribute something highly risky.   But it is up to any TLP.  Including the 
>> IPMC.  And so the Incubator can do whatever it wants within limits.  Any of 
>> us should protest if the IPMC starts allowing releases with high risk.  But 
>> with the disclaimer and -incubating suffixes, the risk of many 
>> non-compliance issues are low, even CatX and binary inclusions.
>> 
>> Whether the incubator needs to have a secondary vote is not required by the 
>> above.  IPMC members could drop in on the podling vote thread.  Podlings 
>> with 3 active mentors that vote on the podling's vote thread could be deemed 
>> sufficient.
>> 
> 
> Although not a "real" PMC, we do need to provide legal protection for each 
> PPMC and distributing releases is the time that most legal considerations 
> "kick in" as it were. So we need a clear "paper trail" of approvals for that 
> PPMC to enjoy the legal protection the foundation exists to provide. The IPMC 
> vote, since the IPMC is, in fact, a true PMC, provides that legal provenance 
> such that, should anything untoward happen, we can clearly show to outside 
> legal entities corporate provenance without having to try to explain the 
> intricacies of podlings, and PPMCs and PMC and et.al. :-)
> 
> Let's also recall that the origin genesis of the Incubator was NOT to provide 
> legal oversight, but rather education and guidance into The Apache Way (TAW). 
> Back then we had way too many projects that were TLP status that lacked even 
> a basic awareness of TAW, and the board, rightfully, considered that a huge 
> problem (this started with the mismanagement of the Jakarta project, which 
> tried to create a sub-foundation within the ASF such that the Jakarta PMC was 
> basically the "board" of that "foundation"... as these projects spun out, 
> problems aplenty ensued). And so the Incubator was created to handle that 
> problem.
> -
> 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 commands, e-mail: general-h...@incubator.apache.org

Re: Podlings, the Incubator, relationships and Apache

[Ross Gardler]

Jim said "Let's also recall that the origin genesis of the Incubator was NOT to 
provide legal oversight, but rather education and guidance into The Apache Way"

I say... HEAR! HEAR!

Get Outlook for Android


From: Jim Jagielski 
Sent: Tuesday, July 2, 2019 4:36:02 AM
To: Incubator General
Subject: Re: Podlings, the Incubator, relationships and Apache



> On Jul 1, 2019, at 1:45 AM, Alex Harui  wrote:
>
> FWIW, I reconcile it as:
>
> Incubator is a PMC and must record a business decision to call something an 
> ASF release in order to place that release under the legal protection of the 
> ASF.  ASF releases may have policy non-compliance issues.  No TLP can decide 
> on its own to never comply with policy.  But the business decision of the 
> costs of delaying a release to correct non-compliance vs risks of 
> distributing a release with any non-compliance is up to the TLP.  VP Legal 
> will assert a risk profile for any non-compliance and VP Legal or any ASF 
> Member or PMC Member should try to stop a release if a TLP decides to 
> distribute something highly risky.   But it is up to any TLP.  Including the 
> IPMC.  And so the Incubator can do whatever it wants within limits.  Any of 
> us should protest if the IPMC starts allowing releases with high risk.  But 
> with the disclaimer and -incubating suffixes, the risk of many non-compliance 
> issues are low, even CatX and binary inclusions.
>
> Whether the incubator needs to have a secondary vote is not required by the 
> above.  IPMC members could drop in on the podling vote thread.  Podlings with 
> 3 active mentors that vote on the podling's vote thread could be deemed 
> sufficient.
>

Although not a "real" PMC, we do need to provide legal protection for each PPMC 
and distributing releases is the time that most legal considerations "kick in" 
as it were. So we need a clear "paper trail" of approvals for that PPMC to 
enjoy the legal protection the foundation exists to provide. The IPMC vote, 
since the IPMC is, in fact, a true PMC, provides that legal provenance such 
that, should anything untoward happen, we can clearly show to outside legal 
entities corporate provenance without having to try to explain the intricacies 
of podlings, and PPMCs and PMC and et.al. :-)

Let's also recall that the origin genesis of the Incubator was NOT to provide 
legal oversight, but rather education and guidance into The Apache Way (TAW). 
Back then we had way too many projects that were TLP status that lacked even a 
basic awareness of TAW, and the board, rightfully, considered that a huge 
problem (this started with the mismanagement of the Jakarta project, which 
tried to create a sub-foundation within the ASF such that the Jakarta PMC was 
basically the "board" of that "foundation"... as these projects spun out, 
problems aplenty ensued). And so the Incubator was created to handle that 
problem.
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: New Project?

[Dave Fisher]

Hi -

To me you have two parts. One fits Apache and the other would need to be 
outside.

(1) Open Source Software which is the library, service and CLI tools. This is 
something that an Apache Community could grow around and be governed in the 
Apache Way. This part can be incubated.

(2) Open Data. Justin refers to Kibble and Pony Mail which are incubating 
projects around consuming Apache Community data mostly. I would point out that 
you could host the data portion of your community elsewhere by some community 
members or others outside of Apache PMCs. Here is a real example. Apache Tika, 
PDFBox and POI PMCs all share a set of regression test documents 
(https://openpreservation.org/blog/2016/10/04/apache-tikas-regression-corpus-tika-1302/)
 and a community member Dominik Stadler 
(https://github.com/centic9/CommonCrawlDocumentDownload) that are retrieved 
from Common Crawl (http://commoncrawl.org) which uses the AWS Public Dataset 
Program (https://aws.amazon.com/opendata/public-datasets/)

Regards,
Dave

> On Jul 2, 2019, at 1:59 PM, Alejandro Caceres  
> wrote:
> 
> Hi Matt,
> 
> Thanks for the response. You are sort of correct, I would say the end goal
> is a service - an open source engine that is able to grab and ingest this
> highly unstructured security information and turn it into something useful
> - then provide that back to the user in a few different forms. One would be
> a web services API for general use exposed to the Internet (a service, like
> you said), and another would be a series of command line tools and
> libraries that others can use to ingest this information easily. the third
> goal would be: not only is the code open source, but all data used in the
> application is available itself, so this could easily be used to run a
> personal node of this information for an organization, scylla.sh is simply
> my instance that I expose to the Internet at large for those that don't
> want to run a "full node". If that is more palatable to the ASF I'm glad to
> make that the focus. In other words: I'm not married to any model here.
> 
> I knew coming in that it's a bit unconventional for Apache, but, I think,
> it is a unique and powerful project that would increase engagement from the
> infosec community in which I personally, as well as my R company have
> some good visibility from. In other words, just testing the waters to see
> how this is received by ASF :).
> 
> Alex
> 
> 
> On Tue, Jul 2, 2019 at 3:44 PM Matt Sicker  wrote:
> 
>> I'm a little unclear about the scope of the project here. This project
>> looks more like a service, and I don't know of any ASF projects that
>> exist to provide services outside the ASF.
>> 
>> On Tue, 2 Jul 2019 at 14:28, Alejandro Caceres
>>  wrote:
>>> 
>>> Hey Folks,
>>> 
>>> I'm interested in submitting a project as a seedling and am looking
>> exactly
>>> where to start. The project is already off the ground, being used by
>> many,
>>> is stable, reasonably mature (it's in alpha release), open source, and
>>> already Apache licensed. I've been looking at a lot of resources to how
>>> best to submit this to Apache and from what I understand I need to:
>>> 
>>> Find a "champion/mentor" for the project and a "sponsor" -> submit an
>>> incubator application -> wait (or do i submit for a vote on general@?)
>> ->
>>> ... -> profit :)
>>> 
>>> For a bit more context, my project is http://scylla.sh or
>>> https://github.com/acaceres2176/scylla. This project aggregates and
>> makes
>>> searchable database leaks and other information security data that is
>> easy
>>> for attackers to find (they have blackhat and underground resources) but
>>> difficult for security professionals trying to defend their network (they
>>> cannot buy stolen data, are not plugged into the blackhat hacker
>> community,
>>> and frankly generally don't know "where to start"). The Scylla engine
>> aims
>>> to even the playing field by making this data available and completely
>> free
>>> for everyone. The feed is meant to power threat intelligence engines to
>> aid
>>> in the defense of both large corporate networks, but also be accessible
>> to
>>> an average user who wants to check what information of theirs has been
>>> leaked. It's a passion project of mine and have been working on it for
>>> several months already. We have several terabytes of data and good
>>> attention from the infosec community.
>>> 
>>> Anyway, sorry for the brain dump above, but I suppose I should mainly
>> ask -
>>> where do I go from here? Do I simply ask this mailing list if there is a
>>> sponsor and champion willing to bring this in as a podling?
>>> 
>>> Thanks!
>>> Alex
>>> 
>>> 
>>> 
>>> --
>>> ___
>>> 
>>> Alejandro Caceres
>>> Hyperion Gray, LLC
>>> Owner/CTO
>> 
>> 
>> 
>> --
>> Matt Sicker 
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: 

Re: New Project?

[Justin Mclean]

Hi,

> Thanks for the response. You are sort of correct, I would say the end goal
> is a service

We do have a couple of project along those lines eg. pony mail and kibble,, so 
that may not be an issue.

Is there an existing code base and a community using it?

Thanks,
Justin

Re: New Project?

[Alejandro Caceres]

Hi Matt,

Thanks for the response. You are sort of correct, I would say the end goal
is a service - an open source engine that is able to grab and ingest this
highly unstructured security information and turn it into something useful
- then provide that back to the user in a few different forms. One would be
a web services API for general use exposed to the Internet (a service, like
you said), and another would be a series of command line tools and
libraries that others can use to ingest this information easily. the third
goal would be: not only is the code open source, but all data used in the
application is available itself, so this could easily be used to run a
personal node of this information for an organization, scylla.sh is simply
my instance that I expose to the Internet at large for those that don't
want to run a "full node". If that is more palatable to the ASF I'm glad to
make that the focus. In other words: I'm not married to any model here.

I knew coming in that it's a bit unconventional for Apache, but, I think,
it is a unique and powerful project that would increase engagement from the
infosec community in which I personally, as well as my R company have
some good visibility from. In other words, just testing the waters to see
how this is received by ASF :).

Alex


On Tue, Jul 2, 2019 at 3:44 PM Matt Sicker  wrote:

> I'm a little unclear about the scope of the project here. This project
> looks more like a service, and I don't know of any ASF projects that
> exist to provide services outside the ASF.
>
> On Tue, 2 Jul 2019 at 14:28, Alejandro Caceres
>  wrote:
> >
> > Hey Folks,
> >
> > I'm interested in submitting a project as a seedling and am looking
> exactly
> > where to start. The project is already off the ground, being used by
> many,
> > is stable, reasonably mature (it's in alpha release), open source, and
> > already Apache licensed. I've been looking at a lot of resources to how
> > best to submit this to Apache and from what I understand I need to:
> >
> > Find a "champion/mentor" for the project and a "sponsor" -> submit an
> > incubator application -> wait (or do i submit for a vote on general@?)
> ->
> > ... -> profit :)
> >
> > For a bit more context, my project is http://scylla.sh or
> > https://github.com/acaceres2176/scylla. This project aggregates and
> makes
> > searchable database leaks and other information security data that is
> easy
> > for attackers to find (they have blackhat and underground resources) but
> > difficult for security professionals trying to defend their network (they
> > cannot buy stolen data, are not plugged into the blackhat hacker
> community,
> > and frankly generally don't know "where to start"). The Scylla engine
> aims
> > to even the playing field by making this data available and completely
> free
> > for everyone. The feed is meant to power threat intelligence engines to
> aid
> > in the defense of both large corporate networks, but also be accessible
> to
> > an average user who wants to check what information of theirs has been
> > leaked. It's a passion project of mine and have been working on it for
> > several months already. We have several terabytes of data and good
> > attention from the infosec community.
> >
> > Anyway, sorry for the brain dump above, but I suppose I should mainly
> ask -
> > where do I go from here? Do I simply ask this mailing list if there is a
> > sponsor and champion willing to bring this in as a podling?
> >
> > Thanks!
> > Alex
> >
> >
> >
> > --
> > ___
> >
> > Alejandro Caceres
> > Hyperion Gray, LLC
> > Owner/CTO
>
>
>
> --
> Matt Sicker 
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

-- 
___

Alejandro Caceres
Hyperion Gray, LLC
Owner/CTO

Re: New disclaimer text

[Greg Stein]

On Tue, Jul 2, 2019 at 1:55 PM Daniel Shahaf  wrote:

> Dave Fisher wrote on Tue, 02 Jul 2019 10:28 -0700:
> > > On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz <
> bdelacre...@codeconsult.ch> wrote:
> > >
> > > Hi,
> > >
> > > On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean <
> jus...@classsoftware.com> wrote:
> > >> ...I put up suggested text changes for an incubator disclaimer here
> [1]...
> > >
> > > Basically just adding this, right?
> > >
> > >> Some of the project releases may not follow ASF policy or have
> > >> incomplete or unknown licensing conditions
> > >
> > > It works for me but I'd say "incubating project" to be clearer.
> >
> > How is this?
> >
> > “Some of the incubating project’s releases may not be fully compliant
> > with ASF policy. For example, releases may have incomplete or unreviewed
> > licensing conditions. Known issues will be described on the project’s
> > status page."
>
> I think the meaning you guys are after is "The artifact may not be in
> compliance with Apache's policies (CatA/CatB/CatX, etc)", but what you
> actually drafted so far can be read as "We do not promise to you that the
> LICENSE file is complete and accurate", which would be a deal breaker to
> downstreams.
>

s/would/may/

As a hobbyist user, I really don't care what is in LICENSE and NOTICE.
Heck, I don't even care if those files are missing.

Cheers,
-g

Re: New Project?

[Matt Sicker]

I'm a little unclear about the scope of the project here. This project
looks more like a service, and I don't know of any ASF projects that
exist to provide services outside the ASF.

On Tue, 2 Jul 2019 at 14:28, Alejandro Caceres
 wrote:
>
> Hey Folks,
>
> I'm interested in submitting a project as a seedling and am looking exactly
> where to start. The project is already off the ground, being used by many,
> is stable, reasonably mature (it's in alpha release), open source, and
> already Apache licensed. I've been looking at a lot of resources to how
> best to submit this to Apache and from what I understand I need to:
>
> Find a "champion/mentor" for the project and a "sponsor" -> submit an
> incubator application -> wait (or do i submit for a vote on general@?)  ->
> ... -> profit :)
>
> For a bit more context, my project is http://scylla.sh or
> https://github.com/acaceres2176/scylla. This project aggregates and makes
> searchable database leaks and other information security data that is easy
> for attackers to find (they have blackhat and underground resources) but
> difficult for security professionals trying to defend their network (they
> cannot buy stolen data, are not plugged into the blackhat hacker community,
> and frankly generally don't know "where to start"). The Scylla engine aims
> to even the playing field by making this data available and completely free
> for everyone. The feed is meant to power threat intelligence engines to aid
> in the defense of both large corporate networks, but also be accessible to
> an average user who wants to check what information of theirs has been
> leaked. It's a passion project of mine and have been working on it for
> several months already. We have several terabytes of data and good
> attention from the infosec community.
>
> Anyway, sorry for the brain dump above, but I suppose I should mainly ask -
> where do I go from here? Do I simply ask this mailing list if there is a
> sponsor and champion willing to bring this in as a podling?
>
> Thanks!
> Alex
>
>
>
> --
> ___
>
> Alejandro Caceres
> Hyperion Gray, LLC
> Owner/CTO



-- 
Matt Sicker 

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

New Project?

[Alejandro Caceres]

Hey Folks,

I'm interested in submitting a project as a seedling and am looking exactly
where to start. The project is already off the ground, being used by many,
is stable, reasonably mature (it's in alpha release), open source, and
already Apache licensed. I've been looking at a lot of resources to how
best to submit this to Apache and from what I understand I need to:

Find a "champion/mentor" for the project and a "sponsor" -> submit an
incubator application -> wait (or do i submit for a vote on general@?)  ->
... -> profit :)

For a bit more context, my project is http://scylla.sh or
https://github.com/acaceres2176/scylla. This project aggregates and makes
searchable database leaks and other information security data that is easy
for attackers to find (they have blackhat and underground resources) but
difficult for security professionals trying to defend their network (they
cannot buy stolen data, are not plugged into the blackhat hacker community,
and frankly generally don't know "where to start"). The Scylla engine aims
to even the playing field by making this data available and completely free
for everyone. The feed is meant to power threat intelligence engines to aid
in the defense of both large corporate networks, but also be accessible to
an average user who wants to check what information of theirs has been
leaked. It's a passion project of mine and have been working on it for
several months already. We have several terabytes of data and good
attention from the infosec community.

Anyway, sorry for the brain dump above, but I suppose I should mainly ask -
where do I go from here? Do I simply ask this mailing list if there is a
sponsor and champion willing to bring this in as a podling?

Thanks!
Alex



-- 
___

Alejandro Caceres
Hyperion Gray, LLC
Owner/CTO

Re: New disclaimer text

[Daniel Shahaf]

Dave Fisher wrote on Tue, 02 Jul 2019 10:28 -0700:
> > On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz 
> >  wrote:
> > 
> > Hi,
> > 
> > On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean  
> > wrote:
> >> ...I put up suggested text changes for an incubator disclaimer here [1]...
> > 
> > Basically just adding this, right?
> > 
> >> Some of the project releases may not follow ASF policy or have
> >> incomplete or unknown licensing conditions
> > 
> > It works for me but I'd say "incubating project" to be clearer.
> 
> How is this?
> 
> “Some of the incubating project’s releases may not be fully compliant 
> with ASF policy. For example, releases may have incomplete or unreviewed 
> licensing conditions. Known issues will be described on the project’s 
> status page."

I think the meaning you guys are after is "The artifact may not be in
compliance with Apache's policies (CatA/CatB/CatX, etc)", but what you
actually drafted so far can be read as "We do not promise to you that the
LICENSE file is complete and accurate", which would be a deal breaker to
downstreams.

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

Re: [Discuss] Graduate Apache OpenWhisk (incubating) as a TLP

[Paul King]

I have been following some of the OpenWhisk traffic on the mailing list but
mostly at arms length, so I thought I would have my first play writing a
Groovy action this evening to see if the process would shed any light on
the project's graduation readiness. The result (with kudos to Markus
Thömmes whose repo I plagiarised):

https://github.com/paulk-asert/openwhisk-groovy

[As an aside: perhaps it belongs in devtools? It seems very similar to the
maven-java example contained in there - let me know if you want a PR.]

Anyway, everything seemed as expected or close to expected in terms of
branding/what I could download/disclaimers etc. With all of your repos and
moving parts on the server side of things, you will no doubt have an
on-going effort in terms of working out what and how to package things
going forward - since things will no doubt keep changing. I don't see any
reason why that on-going effort needs to be done any further within
incubation. There are still things which seem like they might need more
work, like the CLI releases page on github but I see discussions indicating
that folks seem to understand the issues involved.

So from my point of view you seem ready for graduation.

Cheers, Paul.



On Tue, Jul 2, 2019 at 11:45 AM David P Grove  wrote:

>
>
> Hi all,
>
> In the two and a half years that Apache OpenWhisk (incubating) has
> been a part of the Apache incubator, the community has grown, diversified,
> and adapted to the Apache Way. We believe that the project is ready to
> graduate to a TLP.
>
> As a community, we have discussed [1] and voted [2] to graduate to
> a
> TLP, we have worked through the maturity model [3], notified the IPMC that
> we have the intention to graduate [4], discussed our resolution [5, 6] and
> proposed PMC chair [7].
>
> Please see the draft resolution appended below and provide any
> comments or feedback you have on it.
>
> We would like to continue the graduation process and hereby ask you
> all for your opinion on this. The discussion is open for 72 hours, after
> which we will start a [VOTE] on graduation here.
>
> thanks,
>
> --dave
> on behalf of the Apache OpenWhisk PPMC
>
> [1]
>
> https://lists.apache.org/thread.html/8daa3a05148f54ca82458777e2b2b5e25ba99d39dcf8ce7dd85d0188@%3Cdev.openwhisk.apache.org%3E
> [2]
>
> https://lists.apache.org/thread.html/34e5740cdf1ce5f74c9468d9f9b222ba8994f0c63a82777b020cdf10@%3Cdev.openwhisk.apache.org%3E
> [3] https://cwiki.apache.org/confluence/display/OPENWHISK/Project+Maturity
> +Model
> [4]
>
> https://lists.apache.org/thread.html/02dd71dcc6b2f326015954388c61d06d12f982fd64f34ee40e076171@%3Cgeneral.incubator.apache.org%3E
> [5]
>
> https://lists.apache.org/thread.html/5b52f89c9af99fc79c7d466db83be1b299a441f258b8419285359ac5@%3Cdev.openwhisk.apache.org%3E
> [6]
>
> https://lists.apache.org/thread.html/5a44e377f3292a24de13c3a23f82735b82364c6419fab13e997bd91a@%3Cdev.openwhisk.apache.org%3E
> [7]
>
> https://lists.apache.org/thread.html/1c0366181b6812de7ae8f68cb546bb3a4512b53dc4e89edba7b27075@%3Cdev.openwhisk.apache.org%3E
> [8]
>
> https://lists.apache.org/thread.html/1c0366181b6812de7ae8f68cb546bb3a4512b53dc4e89edba7b27075@%3Cdev.openwhisk.apache.org%3E
>
>
> Proposed Resolution for the Apache OpenWhisk project for the ASF Board:
>
> X. Establish the Apache OpenWhisk Project
>
> WHEREAS, the Board of Directors deems it to be in the best interests of the
> Foundation and consistent with the
> Foundation's purpose to establish a Project Management Committee charged
> with the creation and maintenance of
> open-source software, for distribution at no charge to the public, related
> to a platform for building serverless applications with functions.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC),
> to be known as the "Apache OpenWhisk Project",
> be and hereby is established pursuant to Bylaws of the Foundation; and be
> it further
>
> RESOLVED, that the Apache OpenWhisk Project be and hereby is responsible
> for the creation and maintenance of software
> related to a platform for building serverless applications with functions;
> and be it further
>
> RESOLVED, that the office of "Vice President, Apache OpenWhisk" be and
> hereby is created, the person holding such office to
> serve at the direction of the Board of Directors as the chair of the Apache
> OpenWhisk Project, and to have primary responsibility
> for management of the projects within the scope of responsibility of the
> Apache OpenWhisk Project; and be it further
>
> RESOLVED, that the persons listed immediately below be and hereby are
> appointed to serve as the initial members of the
> Apache OpenWhisk Project:
> Bertrand Delacretaz, bdelacre...@apache.org
> Carlos Santana, csantan...@apache.org
> Chetan Mehrotra, chet...@apache.org
> Dave Grove, dgr...@apache.org
> Dominic Kim, styl...@apache.org
> Dragos Dascalita Haut, dra...@apache.org
> James Dubee, du...@apache.org

Re: New disclaimer text

[Dave Fisher]

Hi -

> On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz  
> wrote:
> 
> Hi,
> 
> On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean  
> wrote:
>> ...I put up suggested text changes for an incubator disclaimer here [1]...
> 
> Basically just adding this, right?
> 
>> Some of the project releases may not follow ASF policy or have
>> incomplete or unknown licensing conditions
> 
> It works for me but I'd say "incubating project" to be clearer.

How is this?

“Some of the incubating project’s releases may not be fully compliant with ASF 
policy. For example, releases may have incomplete or unreviewed licensing 
conditions. Known issues will be described on the project’s status page."

> 
>> ...It also been suggested than any known issues be listed in the 
>> disclaimer...
> 
> I don't think that works as modifying the disclaimer to list issues
> will change the digests of the archive that's being voted on - and
> those shouldn't change IMO.
> 
> As Paul suggests in a different thread I'd go for easy to find tickets
> to describe those changes. The disclaimer might point to
> http://incubator.apache.org/release-issues which in turn points to
> those tickets, keyed by release name and version number. Or something
> like that - a permalink that points to the details.

I would suggest that in a revamping of podling status pages that the podling 
can list current issues with each release.

The link to that page is easy: http://incubator.apache.org/projects/

BTW - I’ve changed my thoughts on a Whimsical version of the status data and am 
planning to put these in as AsciiDoc pages / YML into the Incubator’s Git.

Regards,
Dave

> 
> -Bertrand
> 
> -
> 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 commands, e-mail: general-h...@incubator.apache.org

Re: Re: [Discuss] Graduate Apache OpenWhisk (incubating) as a TLP

[Dave Fisher]

Hi -

LGTM!

Some comments inline:

> On Jul 2, 2019, at 8:42 AM, David P Grove  wrote:
> 
> Justin Mclean  wrote on 07/02/2019 05:53:06 AM:
>> 
>> There were a couple of minor issue around branding. communication
>> and releases brought up in the discussion on graduation, I believe
>> most (if not all) of these have been sorted or in progress of being
>> sorted. Would you mind posting a short summary of what the PPMC is
>> going about these issues?
>> 
> 
> Sure.  TL;DR I think your belief is correct; everything raised in that
> discussion is handled or being handled.
> 
> 1. Communication (ie, usage of Slack).
>   a. Culturally, the project has transitioned to using the dev list and
> github issues as the primary channels for technical discussion and decision
> making.
>   b. Updated project website to strengthen guidance on appropriate
> usage of Slack [1]
>   c. Updated Slack configuration to remove historical/obsolete list of
> ibm and adobe email domains from the Slack team sign in page.
>   d. Attempted to change the Slack login page to have a link to our
> open signup page [2], but this level of customization appears to not be
> supported by Slack.
> 
> 2. Branding
>   a. Added a policy on usage of the OpenWhisk trademark to the project
> website [3].

I think that you should send this very well done and detailed page for review 
on tradema...@apache.org

I don’t see this review as blocking in any way, the review is about discussing 
carefully how much the future OpenWhisk PMC is responsible for answering 
trademark questions as opposed to the VP, Brand.

>   b. The PPMC reviewed the lengthy list of non-Apache web pages and
> github projects from the prior thread that mention OpenWhisk.
>   c. Current branding by IBM and Adobe in their respective commercial
> offerings that are based on OpenWhisk is generally consistent with Apache
> policy.
> 
> 3. Releases
>   a. We've given up on using the short form license header in specific
> file types. PRs have been merged across many git repos.  Next releases of
> each component will uniformly use the long form header.
>   b. Dockerhub. (still in progress as we have over 50 repositories in
> the openwhisk organization)
>   i. An initial pass through all repositories to have a minimal
> consistent description has been completed.
>   ii. Our CI/CD system now publishes using "nightly" instead of
> "latest" (completed yesterday).
>   iii. By the end of the week, the "latest" tag on dockerhub will
> uniformly refer to an image built from an official release (not a nightly
> build)
>   c. npmjs.  We reviewed our usage; it was already the case that
> released packages correspond to official source releases.
> 
> --dave
> 
> [1] https://github.com/apache/incubator-openwhisk-website/pull/384
> [2] http://openwhisk.incubator.apache.org/slack.html
> [3] http://openwhisk.incubator.apache.org/trademarks.html


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

Re: Re: [Discuss] Graduate Apache OpenWhisk (incubating) as a TLP

[David P Grove]

Justin Mclean  wrote on 07/02/2019 05:53:06 AM:
>
> There were a couple of minor issue around branding. communication
> and releases brought up in the discussion on graduation, I believe
> most (if not all) of these have been sorted or in progress of being
> sorted. Would you mind posting a short summary of what the PPMC is
> going about these issues?
>

Sure.  TL;DR I think your belief is correct; everything raised in that
discussion is handled or being handled.

1. Communication (ie, usage of Slack).
a. Culturally, the project has transitioned to using the dev list and
github issues as the primary channels for technical discussion and decision
making.
b. Updated project website to strengthen guidance on appropriate
usage of Slack [1]
c. Updated Slack configuration to remove historical/obsolete list of
ibm and adobe email domains from the Slack team sign in page.
d. Attempted to change the Slack login page to have a link to our
open signup page [2], but this level of customization appears to not be
supported by Slack.

2. Branding
a. Added a policy on usage of the OpenWhisk trademark to the project
website [3].
b. The PPMC reviewed the lengthy list of non-Apache web pages and
github projects from the prior thread that mention OpenWhisk.
c. Current branding by IBM and Adobe in their respective commercial
offerings that are based on OpenWhisk is generally consistent with Apache
policy.

3. Releases
a. We've given up on using the short form license header in specific
file types. PRs have been merged across many git repos.  Next releases of
each component will uniformly use the long form header.
b. Dockerhub. (still in progress as we have over 50 repositories in
the openwhisk organization)
i. An initial pass through all repositories to have a minimal
consistent description has been completed.
ii. Our CI/CD system now publishes using "nightly" instead of
"latest" (completed yesterday).
iii. By the end of the week, the "latest" tag on dockerhub will
uniformly refer to an image built from an official release (not a nightly
build)
c. npmjs.  We reviewed our usage; it was already the case that
released packages correspond to official source releases.

--dave

[1] https://github.com/apache/incubator-openwhisk-website/pull/384
[2] http://openwhisk.incubator.apache.org/slack.html
[3] http://openwhisk.incubator.apache.org/trademarks.html

Re: Podlings, the Incubator, relationships and Apache

[Jim Jagielski]

> On Jul 1, 2019, at 1:45 AM, Alex Harui  wrote:
> 
> FWIW, I reconcile it as:
> 
> Incubator is a PMC and must record a business decision to call something an 
> ASF release in order to place that release under the legal protection of the 
> ASF.  ASF releases may have policy non-compliance issues.  No TLP can decide 
> on its own to never comply with policy.  But the business decision of the 
> costs of delaying a release to correct non-compliance vs risks of 
> distributing a release with any non-compliance is up to the TLP.  VP Legal 
> will assert a risk profile for any non-compliance and VP Legal or any ASF 
> Member or PMC Member should try to stop a release if a TLP decides to 
> distribute something highly risky.   But it is up to any TLP.  Including the 
> IPMC.  And so the Incubator can do whatever it wants within limits.  Any of 
> us should protest if the IPMC starts allowing releases with high risk.  But 
> with the disclaimer and -incubating suffixes, the risk of many non-compliance 
> issues are low, even CatX and binary inclusions.
> 
> Whether the incubator needs to have a secondary vote is not required by the 
> above.  IPMC members could drop in on the podling vote thread.  Podlings with 
> 3 active mentors that vote on the podling's vote thread could be deemed 
> sufficient.
> 

Although not a "real" PMC, we do need to provide legal protection for each PPMC 
and distributing releases is the time that most legal considerations "kick in" 
as it were. So we need a clear "paper trail" of approvals for that PPMC to 
enjoy the legal protection the foundation exists to provide. The IPMC vote, 
since the IPMC is, in fact, a true PMC, provides that legal provenance such 
that, should anything untoward happen, we can clearly show to outside legal 
entities corporate provenance without having to try to explain the intricacies 
of podlings, and PPMCs and PMC and et.al. :-)

Let's also recall that the origin genesis of the Incubator was NOT to provide 
legal oversight, but rather education and guidance into The Apache Way (TAW). 
Back then we had way too many projects that were TLP status that lacked even a 
basic awareness of TAW, and the board, rightfully, considered that a huge 
problem (this started with the mismanagement of the Jakarta project, which 
tried to create a sub-foundation within the ASF such that the Jakarta PMC was 
basically the "board" of that "foundation"... as these projects spun out, 
problems aplenty ensued). And so the Incubator was created to handle that 
problem.
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Podlings, the Incubator, relationships and Apache

[Myrle Krantz]

Hey Alex,

The Incubator plays a special role.  We should be willing to take on some
risks in the process of helping newer, or older projects adjust to us.  But
once those adjustments are complete, we should be able to expect TLP's to
"color in the lines".

If you believe that is impossible for your project for some reason, then
you may be trying to do something that just doesn't belong at Apache.  Or
you may have found something about Apache that needs to change.  Either
way, this isn't the right forum.  Many others here have said it too: the
incubator is not the right place to be looking for an exception to the
rules for your favorite TLP.  If you want answers to a concrete question,
please bring it to board@a.o, or, if you would prefer to ask in public,
consider dev@community.a.o.

Please don't be looking for ways to leverage decisions that are
special-made for the incubator to find loopholes for a TLP.

Best Regards,
Myrle


On Mon, Jul 1, 2019 at 7:45 AM Alex Harui  wrote:

> FWIW, I reconcile it as:
>
> Incubator is a PMC and must record a business decision to call something
> an ASF release in order to place that release under the legal protection of
> the ASF.  ASF releases may have policy non-compliance issues.  No TLP can
> decide on its own to never comply with policy.  But the business decision
> of the costs of delaying a release to correct non-compliance vs risks of
> distributing a release with any non-compliance is up to the TLP.  VP Legal
> will assert a risk profile for any non-compliance and VP Legal or any ASF
> Member or PMC Member should try to stop a release if a TLP decides to
> distribute something highly risky.   But it is up to any TLP.  Including
> the IPMC.  And so the Incubator can do whatever it wants within limits.
> Any of us should protest if the IPMC starts allowing releases with high
> risk.  But with the disclaimer and -incubating suffixes, the risk of many
> non-compliance issues are low, even CatX and binary inclusions.
>
> Whether the incubator needs to have a secondary vote is not required by
> the above.  IPMC members could drop in on the podling vote thread.
> Podlings with 3 active mentors that vote on the podling's vote thread could
> be deemed sufficient.
>
> My 2 cents,
> -Alex
>
> On 6/30/19, 12:11 PM, "Davor Bonaci"  wrote:
>
> I do -not- have a problem where this is all tracking towards and
> believe it
> is right, but I do have a problem with how it is justified and
> explained.
>
> People say: "Incubator is a PMC/TLP", "Incubator takes on the resultant
> legal obligations associated w/ any PMC doing a release", "we can NOT
> allow
> any relaxation of the ASF release policy for a TLP", and then conclude
> that
> Incubator can do ~whatever it wants. This logic does not pass the
> consistency test.
>
> So... if you want that [new] people in the future don't trip on this,
> it is
> *necessary* to break this logic somehow.
>
> On Fri, Jun 28, 2019 at 8:31 PM Greg Stein  wrote:
>
> > On Fri, Jun 28, 2019 at 9:59 PM Justin Mclean <
> jus...@classsoftware.com>
> > wrote:
> > >...
> >
> > > >   It appears there is general consensus that "right to distribute
> > closed
> > > source" would be the main and potentially only blocker for
> podlings.
> > >
> > > That is not the case (re this is a blocker) I suggest you read
> that legal
> > > thread again. Also infra makes distribution policy.
> > >
> >
> > *distribution*
> >
> > Infra does not care about the contents. If a PMC says "we +1 the
> contents",
> > then Infra will not second-guess that. Leave out LICENSE, NOTICE, or
> do
> > those files wrong. Include jars, Cat X source. Whatever. We aren't
> going to
> > police that. Binaries in there? Knock yourself out. Legal might get
> on your
> > case, but that's Not Our Problem(tm).
> >
> > If the IPMC says "here is a podling tarball that we will allow",
> then it
> > can be put into distribution. Use whatever rules you want for the
> contents,
> > or lack of rules. Infra just wants it placed into our distribution
> system
> > in a specific way, to ensure correctness, auditing, and resilience.
> >
> > VP Infra has already stated the above. As an Officer of
> Infrastructure, I
> > concur and reiterate that position.
> >
> > Regards,
> > Greg Stein
> > InfraAdmin, ASF
> >
>
>
>

Re: [Discuss] Graduate Apache OpenWhisk (incubating) as a TLP

[Justin Mclean]

Hi,

There were a couple of minor issue around branding. communication and releases 
brought up in the discussion on graduation, I believe most (if not all) of 
these have been sorted or in progress of being sorted. Would you mind posting a 
short summary of what the PPMC is going about these issues?

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

Re: LGPL dependency

[York Shen]

Thanks for your supporting.

I will bring it to general@incubator when vote passed in weex@dev

Best Regards,
York Shen

申远

> 在 2019年7月2日，15:20，Myrle Krantz  写道：
> 
> Hey Jim,
> 
> Thank you for asking.  : o)  Weex is still cutting the release.  It's
> precisely because this can be time-consuming that they asked before they
> started.  They'll bring it for a vote once they have it.
> 
> Best,
> Myrle
> 
> On Mon, Jul 1, 2019 at 6:19 PM Jim Jagielski  wrote:
> 
>> Myrle, did you get all you needed? Enough votes and all to get the release
>> unblocked?
>> 
>>> On Jun 28, 2019, at 11:24 AM, Myrle Krantz  wrote:
>>> 
>>> I've said it on dev@weex, and on private@incubator, but I wanted to make
>>> sure and say it here too.  Weex should cut the release.  We'll figure out
>>> the rest later.  The straw poll on private@incubator also confirms: you
>>> have my support and the support of many of the mentors in the
>> incubator.  I
>>> apologize for us blocking you for so long.
>>> 
>>> Best Regards,
>>> Myrle Krantz
>>> PMC Member, Apache Incubator
>>> 
>>> On Thu, Jun 27, 2019 at 6:06 AM 申远  wrote:
>>> 
 It looks like we have got result[1] from Legal VP, I will bring it here
>> now
 
  1. It's fine if Weex only could include header files under 2-clause
>> BSD
  license from Webkit at compiling time and has a dynamic link to
 Webkit.so
  at runtime.
  2. It's recommended that excluding Webkit.so from Weex convenience
  library. Users would include the code snippet below to include both
>> weex
  and webkit.
 
 
 
   weex_sdk
 
 
 
 
 
   webkit
 
 
 
 
 The following is what I need to consult from Incubator:
 
 Google will ban all apps without 64 bit published in Google Play from
>> 1st,
 August, 2019 [1]. Though it's a good idea of excluding Webkit.so from
 convenience library of Weex, Weex community needs to publish next
>> release
 with 64-bit support ASAP to give users enough time to upgrade Weex. I'd
 like to remain webkit.so in convenience library of Weex only for next
 release.
 
 [1] https://issues.apache.org/jira/browse/LEGAL-464
 [2]
>> https://developer.android.com/distribute/best-practices/develop/64-bit
 
 Best Regards,
 YorkShen
 
 申远
 
 
 Roman Shaposhnik  于2019年6月24日周一 上午7:32写道：
 
> Lets continue this discussion on
> https://issues.apache.org/jira/browse/LEGAL-464 please
> 
> On Sat, Jun 22, 2019 at 2:18 PM Matt Sicker  wrote:
>> 
>> WebKit dates back to KHTML, an LGPL web engine from KDE. It sounds
>> like
>> it’s some WebKit specific files that are BSD licensed. I haven’t
> inspected
>> the individual files, but I suspect that the header files are BSD
> licensed
>> to make linking less of a legal headache.
>> 
>> On Sat, Jun 22, 2019 at 07:11, Craig Russell 
> wrote:
>> 
>>> The Webkit license page https://webkit.org/licensing-webkit/ says
>>> portions licensed under LGPL and BSD licenses.
>>> 
>>> Usually this means it's the user's choice which license to use.
>>> 
>>> We would choose the BSD License for the components that we use.
>>> 
>>> Can you find anywhere a statement that the Webkit.so is licensed only
>>> under LGPL?
>>> 
>>> Craig
>>> 
 On Jun 14, 2019, at 1:40 AM, 申远  wrote:
 
 As mentioned above, Webkit is under dual License(BSD and LPGL) and
> it's
 almost impossible for us to figure out which function is a pure BSD
 function. I don't know
 Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL will
 happen
> or
 not. Perhaps pure BSD header file will lead to pure BSD
> implementation.
 Perhaps?
 
 As for alternative dependency, it's possible if we make some major
>>> changes
 to Weex. But convenience binary of each Weex release includes
> Webkit.so,
 how to solve that problem? Maybe publish two convenience binary,
 one
>>> named
 Weex_WebKit.aar and the other named Weex_BSDKit.aar ? Not sounds
> like a
 good idea to me.
 
 Best Regards,
 YorkShen
 
 申远
 
 
 Sheng Wu  于2019年6月14日周五 下午4:23写道：
 
> Hi York
> 
> I am not a C/C++ coder, so I could be wrong.
> 
> But from I saw, Catalog X dependency required is not right. Like
 Hen
>>> said,
> alternative is an option.
> 
> Such as
> Today’s another incubating project, ShardingSphere.
> When user wants to MySQL sharing, then they needs to accept MySQL
> Driver
> license first(or already accepted).
> But user could use ShardingSphere with PostgreSQL JDBC Driver.
> 
> 
> Sheng Wu
> Apache Skywalking, 

Re: LGPL dependency

[Myrle Krantz]

Hey Jim,

Thank you for asking.  : o)  Weex is still cutting the release.  It's
precisely because this can be time-consuming that they asked before they
started.  They'll bring it for a vote once they have it.

Best,
Myrle

On Mon, Jul 1, 2019 at 6:19 PM Jim Jagielski  wrote:

> Myrle, did you get all you needed? Enough votes and all to get the release
> unblocked?
>
> > On Jun 28, 2019, at 11:24 AM, Myrle Krantz  wrote:
> >
> > I've said it on dev@weex, and on private@incubator, but I wanted to make
> > sure and say it here too.  Weex should cut the release.  We'll figure out
> > the rest later.  The straw poll on private@incubator also confirms: you
> > have my support and the support of many of the mentors in the
> incubator.  I
> > apologize for us blocking you for so long.
> >
> > Best Regards,
> > Myrle Krantz
> > PMC Member, Apache Incubator
> >
> > On Thu, Jun 27, 2019 at 6:06 AM 申远  wrote:
> >
> >> It looks like we have got result[1] from Legal VP, I will bring it here
> now
> >>
> >>   1. It's fine if Weex only could include header files under 2-clause
> BSD
> >>   license from Webkit at compiling time and has a dynamic link to
> >> Webkit.so
> >>   at runtime.
> >>   2. It's recommended that excluding Webkit.so from Weex convenience
> >>   library. Users would include the code snippet below to include both
> weex
> >>   and webkit.
> >>
> >> 
> >>
> >>weex_sdk
> >>
> >> 
> >>
> >> 
> >>
> >>webkit
> >>
> >> 
> >>
> >>
> >> The following is what I need to consult from Incubator:
> >>
> >> Google will ban all apps without 64 bit published in Google Play from
> 1st,
> >> August, 2019 [1]. Though it's a good idea of excluding Webkit.so from
> >> convenience library of Weex, Weex community needs to publish next
> release
> >> with 64-bit support ASAP to give users enough time to upgrade Weex. I'd
> >> like to remain webkit.so in convenience library of Weex only for next
> >> release.
> >>
> >> [1] https://issues.apache.org/jira/browse/LEGAL-464
> >> [2]
> https://developer.android.com/distribute/best-practices/develop/64-bit
> >>
> >> Best Regards,
> >> YorkShen
> >>
> >> 申远
> >>
> >>
> >> Roman Shaposhnik  于2019年6月24日周一 上午7:32写道：
> >>
> >>> Lets continue this discussion on
> >>> https://issues.apache.org/jira/browse/LEGAL-464 please
> >>>
> >>> On Sat, Jun 22, 2019 at 2:18 PM Matt Sicker  wrote:
> 
>  WebKit dates back to KHTML, an LGPL web engine from KDE. It sounds
> like
>  it’s some WebKit specific files that are BSD licensed. I haven’t
> >>> inspected
>  the individual files, but I suspect that the header files are BSD
> >>> licensed
>  to make linking less of a legal headache.
> 
>  On Sat, Jun 22, 2019 at 07:11, Craig Russell 
> >>> wrote:
> 
> > The Webkit license page https://webkit.org/licensing-webkit/ says
> > portions licensed under LGPL and BSD licenses.
> >
> > Usually this means it's the user's choice which license to use.
> >
> > We would choose the BSD License for the components that we use.
> >
> > Can you find anywhere a statement that the Webkit.so is licensed only
> > under LGPL?
> >
> > Craig
> >
> >> On Jun 14, 2019, at 1:40 AM, 申远  wrote:
> >>
> >> As mentioned above, Webkit is under dual License(BSD and LPGL) and
> >>> it's
> >> almost impossible for us to figure out which function is a pure BSD
> >> function. I don't know
> >> Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL will
> >> happen
> >>> or
> >> not. Perhaps pure BSD header file will lead to pure BSD
> >>> implementation.
> >> Perhaps?
> >>
> >> As for alternative dependency, it's possible if we make some major
> > changes
> >> to Weex. But convenience binary of each Weex release includes
> >>> Webkit.so,
> >> how to solve that problem? Maybe publish two convenience binary,
> >> one
> > named
> >> Weex_WebKit.aar and the other named Weex_BSDKit.aar ? Not sounds
> >>> like a
> >> good idea to me.
> >>
> >> Best Regards,
> >> YorkShen
> >>
> >> 申远
> >>
> >>
> >> Sheng Wu  于2019年6月14日周五 下午4:23写道：
> >>
> >>> Hi York
> >>>
> >>> I am not a C/C++ coder, so I could be wrong.
> >>>
> >>> But from I saw, Catalog X dependency required is not right. Like
> >> Hen
> > said,
> >>> alternative is an option.
> >>>
> >>> Such as
> >>> Today’s another incubating project, ShardingSphere.
> >>> When user wants to MySQL sharing, then they needs to accept MySQL
> >>> Driver
> >>> license first(or already accepted).
> >>> But user could use ShardingSphere with PostgreSQL JDBC Driver.
> >>>
> >>>
> >>> Sheng Wu
> >>> Apache Skywalking, ShardingSphere, Zipkin
> >>>
> >>>
> >>>
>  在 2019年6月14日，下午4:15，Hen  写道：
> 
>  Assuming Weex requires Webkit and is unable to work with an
> > alternative,
>  the issue here is that users of Weex