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 > >
