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 <my...@apache.org> 写道： > > 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 <j...@jagunet.com> 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 <my...@apache.org> 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 申远 <shenyua...@gmail.com> 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. >>>> >>>> <dependency> >>>> >>>> <artifactId>weex_sdk</artifactId> >>>> >>>> </dependency> >>>> >>>> <dependency> >>>> >>>> <artifactId>webkit</artifactId> >>>> >>>> </dependency> >>>> >>>> >>>> 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 <ro...@shaposhnik.org> 于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 <boa...@gmail.com> 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 <apache....@gmail.com> >>>>> 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, 申远 <shenyua...@gmail.com> 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 <wu.sheng.841...@gmail.com> 于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 <bay...@apache.org> 写道： >>>>>>>>>> >>>>>>>>>> Assuming Weex requires Webkit and is unable to work with an >>>>>>> alternative, >>>>>>>>>> the issue here is that users of Weex would seem to have to permit >>>>>>> reverse >>>>>>>>>> engineering in their legal terms. Our position has been that that >>>>> goes >>>>>>>>>> beyond the scope of the Apache 2.0 license and would be an >>>>> unpleasant >>>>>>>>>> surprise for users. >>>>>>>>>> >>>>>>>>>> (seem to have to => this is how we've discussed the license; an >>>>>>> actual >>>>>>>>>> court may decide something completely different) >>>>>>>>>> >>>>>>>>>> Looking at Weex's website's description, it does not seem to be >>>>> that a >>>>>>>>> user >>>>>>>>>> of Weex will already have agreed to the terms of Webkit; thus I >>>>> believe >>>>>>>>>> they would be unpleasantly surprised. >>>>>>>>>> >>>>>>>>>> Hen >>>>>>>>>> >>>>>>>>>> On Fri, Jun 14, 2019 at 12:49 AM 申远 <shenyua...@gmail.com> >>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I am a PPMC member of Apache Weex. After serious reviewing of >>>> our >>>>>>>>>>> dependencies, I found there some of the source code we copied >>>> from >>>>>>>>> Webkit >>>>>>>>>>> is actually under LGPL license(Category X) and our license >>>> format >>>>>>> tools >>>>>>>>>>> changed the license header of these files to Apache v2 >>>>> incorrectly. >>>>>>> I'd >>>>>>>>>>> like to hear advice from incubator that whether our actions >>>> below >>>>>>> would >>>>>>>>> fix >>>>>>>>>>> the Category X issue. >>>>>>>>>>> >>>>>>>>>>> First of all, License for Webkit is complicated, as it's said >>>> that >>>>>>>>> "WebKit >>>>>>>>>>> is open source software with portions licensed under the LGPL >>>> and >>>>> BSD >>>>>>>>>>> licenses available here." [1]. >>>>>>>>>>> >>>>>>>>>>> Now, Weex includes 1500 header files( .h files) from Webkit at >>>>>>> compiling >>>>>>>>>>> stage and around 150 of the are under BSD License. At runtime, >>>>> Weex >>>>>>> will >>>>>>>>>>> dynamic links to the shared library of Webkit. >>>>>>>>>>> >>>>>>>>>>> After some major change, Weex could just include around 50 >>>>> headers(.h >>>>>>>>>>> files) at compiling stage and all of them are under BSD license. >>>>> At >>>>>>>>>>> runtime, Weex still needs to dynamic links to the shared library >>>>> of >>>>>>>>> Webkit >>>>>>>>>>> as before. >>>>>>>>>>> >>>>>>>>>>> As Webkit is under dual license, and it's almost impossible for >>>>> us to >>>>>>>>>>> figure out whether there is an function call chain like >>>>>>>>>>> Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL.apiD. >>>> I'd >>>>>>> like >>>>>>>>> to >>>>>>>>>>> know our proposed change is enough to fix the Category X >>>>> dependency. >>>>>>>>>>> >>>>>>>>>>> [1] https://webkit.org/licensing-webkit/ >>>>>>>>>>> >>>>>>>>>>> Best Regards, >>>>>>>>>>> YorkShen >>>>>>>>>>> >>>>>>>>>>> 申远 >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>>>>>>>> For additional commands, e-mail: >>>> general-h...@incubator.apache.org >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> Craig L Russell >>>>>>> c...@apache.org >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>>>>>> For additional commands, e-mail: general-h...@incubator.apache.org >>>>>>> >>>>>>> -- >>>>>> Matt Sicker <boa...@gmail.com> >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 >> >>
