Re: LGPL dependency
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
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
Re: LGPL dependency
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 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
Re: LGPL dependency
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 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 >
Re: LGPL dependency
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 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 申远 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
Re: LGPL dependency
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 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 申远 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:
Re: LGPL dependency
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 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 申远 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
Re: LGPL dependency
ในวันที่ ศ. 21 มิ.ย. 2019 15:37 申远 เขียนว่า: > 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,
Re: LGPL dependency
Hi, > 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. Not quite actually it not dual licensed in the tradition l sense. It’s not licensed A or B but it’s licensed A and B as parts are A licensed and parts are B licensed. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: LGPL dependency
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 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 申远 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
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
Re: LGPL dependency
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 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: LGPL dependency
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 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: LGPL dependency
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 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: LGPL dependency
Hi - > On Jun 14, 2019, at 5:08 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. Exactly. Please bring this to Legal Discuss as a platform dependency. In other words if on Android you must WebKit then it wouldn’t surprise a downstream. Regards, Dave > >> 在 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 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: LGPL dependency
Hi Merle, A footnote on your list below. Sent from my iPhone > On Jun 14, 2019, at 2:39 AM, Myrle Krantz wrote: > > I feel like the answers provided here up till now are too simple. I > believe we have projects at Apache which seem to be using, or have used > Webkit: ( > https://issues.apache.org/jira/browse/COUCHDB-232?jql=text%20~%20%22webkit%22 > ) > * Flex > * Myfaces > * Shindig (?) > * Cordova > * Wave > * Corinthia This type of licensing issue is what caused Corinthia to fail Incubation. (Actually the insistence by a PPMC member that everything be instantly pure killed developer desire.) Please be careful using retired podlings for licensing examples. Regards, Dave > * Netbeans > * Apollo > > I'm not completely confident of that list, since some of these projects may > be running *in* webkit-based browsers. It's hard to determine for certain > while skimming Jira issues in projects I'm not involved in. : o) So please > don't treat this list as authoritative. But if I'm reading that correctly, > there are already several Apache TLP projects which use Webkit. > > So this question may have been seen before. Justin, one of the projects > which seems to currently be using Webkit is Flex. Given the weird > part-by-part licensing, how did Flex justify it's decision? Or am I > misreading, and Webkit is just an environment for Flex? > > My hope (probably too naive) is that if Weex is using only the part of > Webkit that can be accessed via BSD-licensed headers, that that is enough > to say they are using only a BSD-licensed run-time dependency. > > But if it's all open source, one possibility is to build a Webkit binary > without the LGPL parts. I haven't looked at how nice their build process > is. Building webkit without certain parts might be hard. YorkShen's > suggestion to replace Webkit might be easier. > > Your thoughts? > > Best Regards, > Myrle - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: LGPL dependency
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 commands, e-mail: general-h...@incubator.apache.org
Re: LGPL dependency
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
Re: LGPL dependency
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. Not the same situation I’m sorry. Webkit and was not a required dependancy and no code form it was in the code base. I would need to double check, but I think it was only used in StageWebView so you could embed webpages in AIR applications. It was an optional feature in one of the runtimes the Flex SDK targeted supplied by a 3rd party. The Flex SDK contained no WebKit code nor was Webkit included in any releases including the connivance binaries. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: LGPL dependency
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. Best Regards, York Shen 申远 > 在 2019年6月14日,18:37,Justin Mclean 写道: > > Hi, > >> So this question may have been seen before. Justin, one of the projects >> which seems to currently be using Webkit is Flex. Given the weird >> part-by-part licensing, how did Flex justify it's decision? Or am I >> misreading, and Webkit is just an environment for Flex? > > It just an environment, there no source code from webkit in Flex to my > knowledge. The other projects I’m not aware of how they used it. > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org >
Re: LGPL dependency
Hi, > So this question may have been seen before. Justin, one of the projects > which seems to currently be using Webkit is Flex. Given the weird > part-by-part licensing, how did Flex justify it's decision? Or am I > misreading, and Webkit is just an environment for Flex? It just an environment, there no source code from webkit in Flex to my knowledge. The other projects I’m not aware of how they used it. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: LGPL dependency
I feel like the answers provided here up till now are too simple. I believe we have projects at Apache which seem to be using, or have used Webkit: ( https://issues.apache.org/jira/browse/COUCHDB-232?jql=text%20~%20%22webkit%22 ) * Flex * Myfaces * Shindig (?) * Cordova * Wave * Corinthia * Netbeans * Apollo I'm not completely confident of that list, since some of these projects may be running *in* webkit-based browsers. It's hard to determine for certain while skimming Jira issues in projects I'm not involved in. : o) So please don't treat this list as authoritative. But if I'm reading that correctly, there are already several Apache TLP projects which use Webkit. So this question may have been seen before. Justin, one of the projects which seems to currently be using Webkit is Flex. Given the weird part-by-part licensing, how did Flex justify it's decision? Or am I misreading, and Webkit is just an environment for Flex? My hope (probably too naive) is that if Weex is using only the part of Webkit that can be accessed via BSD-licensed headers, that that is enough to say they are using only a BSD-licensed run-time dependency. But if it's all open source, one possibility is to build a Webkit binary without the LGPL parts. I haven't looked at how nice their build process is. Building webkit without certain parts might be hard. YorkShen's suggestion to replace Webkit might be easier. Your thoughts? Best Regards, Myrle
Re: LGPL dependency
> > Sorry to say, you have to > 1. Make that clear(I agree it is hard to do, even harder to recheck for > incubator, hope don’t need to do that) > Or > 2. Seek for an alternative. Option 1 is not realistic. However, Weex could switch from Webkit dependency to V8 [1] which is under BSD License. Though this also means a great deal of work. PS: Weex used to have V8 as its dependency until we figured out that JavaScriptCore(a component in Webkit) has better performance. We have to switch back to a poor performance dependency due to LGPL issue. Ironical enough for me. [1] https://github.com/v8/v8/blob/master/LICENSE Best Regards, York Shen 申远 在 2019年6月14日,16:58,Sheng Wu 写道: Inline. Sheng Wu Apache Skywalking, ShardingSphere, Zipkin 在 2019年6月14日,下午4:40,申远 写道: 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? Sorry to say, you have to 1. Make that clear(I agree it is hard to do, even harder to recheck for incubator, hope don’t need to do that) Or 2. Seek for an alternative. 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. I doubt we could do `Weex_WebKit.aar` as convenience binary, because of Catalog X license. More important is that LGPL dependency should not in source and binary under ASF. You could do a re-distribution out-of-ASF, by not using weex/Apache weex/etc..(Please correct me if I am wrong) 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 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 申远 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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: LGPL dependency
Inline. Sheng Wu Apache Skywalking, ShardingSphere, Zipkin > 在 2019年6月14日,下午4:40,申远 写道: > > 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? Sorry to say, you have to 1. Make that clear(I agree it is hard to do, even harder to recheck for incubator, hope don’t need to do that) Or 2. Seek for an alternative. > > 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. I doubt we could do `Weex_WebKit.aar` as convenience binary, because of Catalog X license. More important is that LGPL dependency should not in source and binary under ASF. You could do a re-distribution out-of-ASF, by not using weex/Apache weex/etc..(Please correct me if I am wrong) > > 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 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 申远 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 >> >> - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: LGPL dependency
Hi, > As mentioned above, Webkit is under dual License(BSD and LPGL) It that was the was you would be OK dual licensed usually mean you can choose the license you want to use. Sadly as you say this is not the case here but "WebKit is open source software with portions licensed under the LGPL and BSD”. > and it’s almost impossible for us to figure out which function is a pure BSD > function. Can Weex work without webkit? It’s OK if it’s an optional dependancy on LGPL code. If not OK if it requires it. You can’t include LGPL code in a release. It might be possible for a 3rd party to distribute one. 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
Re: LGPL dependency
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 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 申远 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 > >
Re: LGPL dependency
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 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 申远 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
Re: LGPL dependency
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 申远 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 > > 申远 >
Re: LGPL dependency
> > In the link your shared, there is this > > For example, if you distribute copies of the library, whether gratis or > for a fee, you must give the recipients all the rights that we gave you. > You must make sure that they, too, receive or can get the source code. This is just the content of LGPL, so we are still talking about LGPL. I understand the LPGL is under category X and I am not going to change that. If that possible, week don’t depend on this in runtime? Dynamic links are > same as Java dependency, which should not be allowed. IMHO, I think they are actually different. There is a very good chance for any serious C/C++ program dynamically linking to Glibc, which is under LGPL. A simple *malloc *(included in Glibc) in any C/C++ program will cause you have a dynamic link to LGPL library. Best Regards, York Shen 申远 在 2019年6月14日,16:03,Sheng Wu 写道: Hi, In the link your shared, there is this For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. This is not compatible with our Apache 2.0 and Apache public good goal. Apache software should allow all users to use as their wish, even don’t open source again, sell the fork/mutation versions as they will. LGPL has been discussed many times, but that is not the only concern here. If that possible, week don’t depend on this in runtime? Dynamic links are same as Java dependency, which should not be allowed. This is my personal perspective only. Sheng Wu Apache Skywalking, ShardingSphere, Zipkin 在 2019年6月14日,下午3:48,申远 写道: 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
Re: LGPL dependency
Hi, In the link your shared, there is this > For example, if you distribute copies of the library, whether gratis or for a > fee, you must give the recipients all the rights that we gave you. You must > make sure that they, too, receive or can get the source code. This is not compatible with our Apache 2.0 and Apache public good goal. Apache software should allow all users to use as their wish, even don’t open source again, sell the fork/mutation versions as they will. LGPL has been discussed many times, but that is not the only concern here. If that possible, week don’t depend on this in runtime? Dynamic links are same as Java dependency, which should not be allowed. This is my personal perspective only. Sheng Wu Apache Skywalking, ShardingSphere, Zipkin > 在 2019年6月14日,下午3:48,申远 写道: > > 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