Re: Request for Temporary Exception for LGPL Dependency in Apache KIE Podling
tison, We've talked with the Hibernate team, and Alex has been a Hibernate contributor. They've sent out emails to the list of contributors asking about switching. We don't have a firm date yet, as you know these things take time, but they are actively working on it. On 2024/03/05 17:35:50 tison wrote: > Thanks for reaching out Alex :D > > I agree with PJ and emphasize that we should highlight the license > issue on release. > > Also, for others in this thread, the thorough solution described above is: > > > The Hibernate team is in the process of relicensing from LGPL to Apache > > License 2.0. > > To Alex: > > How much confidence do you have in this direction? Are you involved in > this effort? > > What if the relicensing doesn't happen? Do you have an alternative plan? > > Best, > tison. > > Alex Porcelli 于2024年3月6日周三 01:25写道: > > > > Thank you PJ! This is very helpful! > > > > On Tue, Mar 5, 2024 at 12:23 PM PJ Fanning wrote: > > > > > > https://incubator.apache.org/policy/incubation.html#disclaimers > > > > > > Have a look at the Disclaimers doc. If you use the WIP Disclaimer then you > > > can do releases that are not fully ASF compliant. It would be good to > > > document clearly about this dependency license issue. > > > > > > > > > > > > On Tue 5 Mar 2024, 17:53 Alex Porcelli, wrote: > > > > > > > Dear Members of the Apache Incubator, > > > > > > > > I hope this email finds you well. My name is Alex Porcelli, and I am > > > > part of the Apache KIE podling community [1]. I am reaching out to > > > > discuss a matter regarding a dependency we have under LGPL, which > > > > falls under Category X according to Apache guidelines. > > > > > > > > The dependency is Hibernate ORM [2], the only supported JPA provider > > > > for Quarkus [3] - the primary runtime provider for Apache KIE podling. > > > > > > > > However, I'd like to emphasize the urgency of our situation. Our > > > > community has dedicated substantial effort over the past six months to > > > > prepare for our initial Apache release. Unfortunately, this delay in > > > > releasing Apache KIE is unprecedented for this community, and it is > > > > critical for us to deliver new releases promptly. Not only does our > > > > large user base eagerly anticipate a new release, but older versions > > > > may also pose security vulnerabilities (CVEs). Additionally, with our > > > > previous release process through Red Hat decommissioned, Apache now > > > > stands as our sole means of distribution. > > > > > > > > Given these circumstances, I kindly ask the Apache Incubator to > > > > consider granting us a temporary exception to maintain the LGPL > > > > dependency for our initial releases. We understand the importance of > > > > adhering to Apache licensing requirements and are willing to make > > > > necessary adjustments while ensuring compliance. However, we believe > > > > that allowing us to proceed with proper disclaimers in place would > > > > enable us to maintain momentum and meet the expectations of our user > > > > community. > > > > > > > > Furthermore, I would like to inform you that the Hibernate team is in > > > > the process of relicensing from LGPL to ASLv3, as indicated in their > > > > recent blog post [4]. This transition aligns with our long-term goals > > > > and demonstrates our commitment to compliance with Apache guidelines. > > > > > > > > We are open to any guidance or suggestions from the Incubator PMC on > > > > how best to proceed. > > > > > > > > Thank you for considering our request. > > > > > > > > Best regards, > > > > Alex Porcelli > > > > Apache KIE Podling Community Member > > > > > > > > [1] - Apache KIE: https://kie.apache.org/ > > > > [2] - Hibernate ORM: https://hibernate.org/orm/ > > > > [3] - Quarkus: https://quarkus.io/ > > > > [4] - Blog post on relicensing: > > > > https://in.relation.to/2023/11/18/license/ > > > > > > > > - > > > > 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 > > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Request for Temporary Exception for LGPL Dependency in Apache KIE Podling
tison, First and foremost, as a past Hibernate contributor with personal relationship with Hibernate team members I’m very aware of this plan to change license… and they are finally reaching a point that this has been communicated in public :) - so I have a high level of confidence that the team behind this is actively working on this… But, relicensing is not simple… and we definitely should plan for the situation that Hibernate just can’t do it. In this case, we have a few options (non-exclusive): - adjust API level to just JPA and hack around some tests using OpenJPA - in case of core operations, that might be risky to use unsupported library (ie. OpenJPA for Quarkus in a production code)… we can always go back to JDBC. So, we are not neglecting and are prepared to react in different ways. On Tue, Mar 5, 2024 at 12:39 PM tison wrote: > Thanks for reaching out Alex :D > > I agree with PJ and emphasize that we should highlight the license > issue on release. > > Also, for others in this thread, the thorough solution described above is: > > > The Hibernate team is in the process of relicensing from LGPL to Apache > License 2.0. > > To Alex: > > How much confidence do you have in this direction? Are you involved in > this effort? > > What if the relicensing doesn't happen? Do you have an alternative plan? > > Best, > tison. > > Alex Porcelli 于2024年3月6日周三 01:25写道: > > > > Thank you PJ! This is very helpful! > > > > On Tue, Mar 5, 2024 at 12:23 PM PJ Fanning wrote: > > > > > > https://incubator.apache.org/policy/incubation.html#disclaimers > > > > > > Have a look at the Disclaimers doc. If you use the WIP Disclaimer then > you > > > can do releases that are not fully ASF compliant. It would be good to > > > document clearly about this dependency license issue. > > > > > > > > > > > > On Tue 5 Mar 2024, 17:53 Alex Porcelli, wrote: > > > > > > > Dear Members of the Apache Incubator, > > > > > > > > I hope this email finds you well. My name is Alex Porcelli, and I am > > > > part of the Apache KIE podling community [1]. I am reaching out to > > > > discuss a matter regarding a dependency we have under LGPL, which > > > > falls under Category X according to Apache guidelines. > > > > > > > > The dependency is Hibernate ORM [2], the only supported JPA provider > > > > for Quarkus [3] - the primary runtime provider for Apache KIE > podling. > > > > > > > > However, I'd like to emphasize the urgency of our situation. Our > > > > community has dedicated substantial effort over the past six months > to > > > > prepare for our initial Apache release. Unfortunately, this delay in > > > > releasing Apache KIE is unprecedented for this community, and it is > > > > critical for us to deliver new releases promptly. Not only does our > > > > large user base eagerly anticipate a new release, but older versions > > > > may also pose security vulnerabilities (CVEs). Additionally, with our > > > > previous release process through Red Hat decommissioned, Apache now > > > > stands as our sole means of distribution. > > > > > > > > Given these circumstances, I kindly ask the Apache Incubator to > > > > consider granting us a temporary exception to maintain the LGPL > > > > dependency for our initial releases. We understand the importance of > > > > adhering to Apache licensing requirements and are willing to make > > > > necessary adjustments while ensuring compliance. However, we believe > > > > that allowing us to proceed with proper disclaimers in place would > > > > enable us to maintain momentum and meet the expectations of our user > > > > community. > > > > > > > > Furthermore, I would like to inform you that the Hibernate team is in > > > > the process of relicensing from LGPL to ASLv3, as indicated in their > > > > recent blog post [4]. This transition aligns with our long-term goals > > > > and demonstrates our commitment to compliance with Apache guidelines. > > > > > > > > We are open to any guidance or suggestions from the Incubator PMC on > > > > how best to proceed. > > > > > > > > Thank you for considering our request. > > > > > > > > Best regards, > > > > Alex Porcelli > > > > Apache KIE Podling Community Member > > > > > > > > [1] - Apache KIE: https://kie.apache.org/ > > >
Re: Request for Temporary Exception for LGPL Dependency in Apache KIE Podling
Thanks for reaching out Alex :D I agree with PJ and emphasize that we should highlight the license issue on release. Also, for others in this thread, the thorough solution described above is: > The Hibernate team is in the process of relicensing from LGPL to Apache > License 2.0. To Alex: How much confidence do you have in this direction? Are you involved in this effort? What if the relicensing doesn't happen? Do you have an alternative plan? Best, tison. Alex Porcelli 于2024年3月6日周三 01:25写道: > > Thank you PJ! This is very helpful! > > On Tue, Mar 5, 2024 at 12:23 PM PJ Fanning wrote: > > > > https://incubator.apache.org/policy/incubation.html#disclaimers > > > > Have a look at the Disclaimers doc. If you use the WIP Disclaimer then you > > can do releases that are not fully ASF compliant. It would be good to > > document clearly about this dependency license issue. > > > > > > > > On Tue 5 Mar 2024, 17:53 Alex Porcelli, wrote: > > > > > Dear Members of the Apache Incubator, > > > > > > I hope this email finds you well. My name is Alex Porcelli, and I am > > > part of the Apache KIE podling community [1]. I am reaching out to > > > discuss a matter regarding a dependency we have under LGPL, which > > > falls under Category X according to Apache guidelines. > > > > > > The dependency is Hibernate ORM [2], the only supported JPA provider > > > for Quarkus [3] - the primary runtime provider for Apache KIE podling. > > > > > > However, I'd like to emphasize the urgency of our situation. Our > > > community has dedicated substantial effort over the past six months to > > > prepare for our initial Apache release. Unfortunately, this delay in > > > releasing Apache KIE is unprecedented for this community, and it is > > > critical for us to deliver new releases promptly. Not only does our > > > large user base eagerly anticipate a new release, but older versions > > > may also pose security vulnerabilities (CVEs). Additionally, with our > > > previous release process through Red Hat decommissioned, Apache now > > > stands as our sole means of distribution. > > > > > > Given these circumstances, I kindly ask the Apache Incubator to > > > consider granting us a temporary exception to maintain the LGPL > > > dependency for our initial releases. We understand the importance of > > > adhering to Apache licensing requirements and are willing to make > > > necessary adjustments while ensuring compliance. However, we believe > > > that allowing us to proceed with proper disclaimers in place would > > > enable us to maintain momentum and meet the expectations of our user > > > community. > > > > > > Furthermore, I would like to inform you that the Hibernate team is in > > > the process of relicensing from LGPL to ASLv3, as indicated in their > > > recent blog post [4]. This transition aligns with our long-term goals > > > and demonstrates our commitment to compliance with Apache guidelines. > > > > > > We are open to any guidance or suggestions from the Incubator PMC on > > > how best to proceed. > > > > > > Thank you for considering our request. > > > > > > Best regards, > > > Alex Porcelli > > > Apache KIE Podling Community Member > > > > > > [1] - Apache KIE: https://kie.apache.org/ > > > [2] - Hibernate ORM: https://hibernate.org/orm/ > > > [3] - Quarkus: https://quarkus.io/ > > > [4] - Blog post on relicensing: https://in.relation.to/2023/11/18/license/ > > > > > > - > > > 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: Request for Temporary Exception for LGPL Dependency in Apache KIE Podling
Thank you PJ! This is very helpful! On Tue, Mar 5, 2024 at 12:23 PM PJ Fanning wrote: > > https://incubator.apache.org/policy/incubation.html#disclaimers > > Have a look at the Disclaimers doc. If you use the WIP Disclaimer then you > can do releases that are not fully ASF compliant. It would be good to > document clearly about this dependency license issue. > > > > On Tue 5 Mar 2024, 17:53 Alex Porcelli, wrote: > > > Dear Members of the Apache Incubator, > > > > I hope this email finds you well. My name is Alex Porcelli, and I am > > part of the Apache KIE podling community [1]. I am reaching out to > > discuss a matter regarding a dependency we have under LGPL, which > > falls under Category X according to Apache guidelines. > > > > The dependency is Hibernate ORM [2], the only supported JPA provider > > for Quarkus [3] - the primary runtime provider for Apache KIE podling. > > > > However, I'd like to emphasize the urgency of our situation. Our > > community has dedicated substantial effort over the past six months to > > prepare for our initial Apache release. Unfortunately, this delay in > > releasing Apache KIE is unprecedented for this community, and it is > > critical for us to deliver new releases promptly. Not only does our > > large user base eagerly anticipate a new release, but older versions > > may also pose security vulnerabilities (CVEs). Additionally, with our > > previous release process through Red Hat decommissioned, Apache now > > stands as our sole means of distribution. > > > > Given these circumstances, I kindly ask the Apache Incubator to > > consider granting us a temporary exception to maintain the LGPL > > dependency for our initial releases. We understand the importance of > > adhering to Apache licensing requirements and are willing to make > > necessary adjustments while ensuring compliance. However, we believe > > that allowing us to proceed with proper disclaimers in place would > > enable us to maintain momentum and meet the expectations of our user > > community. > > > > Furthermore, I would like to inform you that the Hibernate team is in > > the process of relicensing from LGPL to ASLv3, as indicated in their > > recent blog post [4]. This transition aligns with our long-term goals > > and demonstrates our commitment to compliance with Apache guidelines. > > > > We are open to any guidance or suggestions from the Incubator PMC on > > how best to proceed. > > > > Thank you for considering our request. > > > > Best regards, > > Alex Porcelli > > Apache KIE Podling Community Member > > > > [1] - Apache KIE: https://kie.apache.org/ > > [2] - Hibernate ORM: https://hibernate.org/orm/ > > [3] - Quarkus: https://quarkus.io/ > > [4] - Blog post on relicensing: https://in.relation.to/2023/11/18/license/ > > > > - > > 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: Request for Temporary Exception for LGPL Dependency in Apache KIE Podling
https://incubator.apache.org/policy/incubation.html#disclaimers Have a look at the Disclaimers doc. If you use the WIP Disclaimer then you can do releases that are not fully ASF compliant. It would be good to document clearly about this dependency license issue. On Tue 5 Mar 2024, 17:53 Alex Porcelli, wrote: > Dear Members of the Apache Incubator, > > I hope this email finds you well. My name is Alex Porcelli, and I am > part of the Apache KIE podling community [1]. I am reaching out to > discuss a matter regarding a dependency we have under LGPL, which > falls under Category X according to Apache guidelines. > > The dependency is Hibernate ORM [2], the only supported JPA provider > for Quarkus [3] - the primary runtime provider for Apache KIE podling. > > However, I'd like to emphasize the urgency of our situation. Our > community has dedicated substantial effort over the past six months to > prepare for our initial Apache release. Unfortunately, this delay in > releasing Apache KIE is unprecedented for this community, and it is > critical for us to deliver new releases promptly. Not only does our > large user base eagerly anticipate a new release, but older versions > may also pose security vulnerabilities (CVEs). Additionally, with our > previous release process through Red Hat decommissioned, Apache now > stands as our sole means of distribution. > > Given these circumstances, I kindly ask the Apache Incubator to > consider granting us a temporary exception to maintain the LGPL > dependency for our initial releases. We understand the importance of > adhering to Apache licensing requirements and are willing to make > necessary adjustments while ensuring compliance. However, we believe > that allowing us to proceed with proper disclaimers in place would > enable us to maintain momentum and meet the expectations of our user > community. > > Furthermore, I would like to inform you that the Hibernate team is in > the process of relicensing from LGPL to ASLv3, as indicated in their > recent blog post [4]. This transition aligns with our long-term goals > and demonstrates our commitment to compliance with Apache guidelines. > > We are open to any guidance or suggestions from the Incubator PMC on > how best to proceed. > > Thank you for considering our request. > > Best regards, > Alex Porcelli > Apache KIE Podling Community Member > > [1] - Apache KIE: https://kie.apache.org/ > [2] - Hibernate ORM: https://hibernate.org/orm/ > [3] - Quarkus: https://quarkus.io/ > [4] - Blog post on relicensing: https://in.relation.to/2023/11/18/license/ > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Request for Temporary Exception for LGPL Dependency in Apache KIE Podling
Dear Members of the Apache Incubator, I hope this email finds you well. My name is Alex Porcelli, and I am part of the Apache KIE podling community [1]. I am reaching out to discuss a matter regarding a dependency we have under LGPL, which falls under Category X according to Apache guidelines. The dependency is Hibernate ORM [2], the only supported JPA provider for Quarkus [3] - the primary runtime provider for Apache KIE podling. However, I'd like to emphasize the urgency of our situation. Our community has dedicated substantial effort over the past six months to prepare for our initial Apache release. Unfortunately, this delay in releasing Apache KIE is unprecedented for this community, and it is critical for us to deliver new releases promptly. Not only does our large user base eagerly anticipate a new release, but older versions may also pose security vulnerabilities (CVEs). Additionally, with our previous release process through Red Hat decommissioned, Apache now stands as our sole means of distribution. Given these circumstances, I kindly ask the Apache Incubator to consider granting us a temporary exception to maintain the LGPL dependency for our initial releases. We understand the importance of adhering to Apache licensing requirements and are willing to make necessary adjustments while ensuring compliance. However, we believe that allowing us to proceed with proper disclaimers in place would enable us to maintain momentum and meet the expectations of our user community. Furthermore, I would like to inform you that the Hibernate team is in the process of relicensing from LGPL to ASLv3, as indicated in their recent blog post [4]. This transition aligns with our long-term goals and demonstrates our commitment to compliance with Apache guidelines. We are open to any guidance or suggestions from the Incubator PMC on how best to proceed. Thank you for considering our request. Best regards, Alex Porcelli Apache KIE Podling Community Member [1] - Apache KIE: https://kie.apache.org/ [2] - Hibernate ORM: https://hibernate.org/orm/ [3] - Quarkus: https://quarkus.io/ [4] - Blog post on relicensing: https://in.relation.to/2023/11/18/license/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
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, ShardingSphe
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 w
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 agr
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 fo
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: general-unsubscr...@incubator.apa
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 commands
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
LGPL dependency
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: Toree's LGPL Dependency resolved!
On Thu, Sep 29, 2016 at 1:18 PM, Gino Bustelo wrote: > Just wanted to announce that the Apache Toree team was able to work with > the JeroMQ (https://github.com/zeromq/jeromq) team to get their library > relicensed as MPL v2. This is a key milestone for the Toree project, as it > allow us to produce regular releases. > > This is a great example of inter-OSS communities working together. > Very good news !!! Congratulations, and let's get the release out now !!! -- Luciano Resende http://twitter.com/lresende1975 http://lresende.blogspot.com/
Re: Toree's LGPL Dependency resolved!
Congrats guys! This is great news On Thu, Sep 29, 2016 at 1:18 PM, Gino Bustelo wrote: > Just wanted to announce that the Apache Toree team was able to work with > the JeroMQ (https://github.com/zeromq/jeromq) team to get their library > relicensed as MPL v2. This is a key milestone for the Toree project, as it > allow us to produce regular releases. > > This is a great example of inter-OSS communities working together. >
Toree's LGPL Dependency resolved!
Just wanted to announce that the Apache Toree team was able to work with the JeroMQ (https://github.com/zeromq/jeromq) team to get their library relicensed as MPL v2. This is a key milestone for the Toree project, as it allow us to produce regular releases. This is a great example of inter-OSS communities working together.
Re: Update on Apache Toree and LGPL dependency
Brilliant :) On Thursday, March 17, 2016, Chip Senkbeil wrote: > Just wanted to give a status update with this one. JeroMQ is down to just > four contributors that have not responded. The current, active committers > for JeroMQ have reverted the commits for one of the contributors here: > > https://github.com/zeromq/jeromq/pull/333 > > So, progress is still being made on this one! > > > +1 > > > > > On Mar 6, 2016, at 6:58 PM, Gino Bustelo > wrote: > > > > > > @john The 0mq ecosystem is made up of many projects of different sizes > and maturity. > > In the case of JeroMQ, the committers are showing an overwhelming > momentum to transition to > > MPL. I don't see any reason for us to consider any other alternative at > this juncture. > > > > > > Gino B. > > > > > >> On Mar 5, 2016, at 11:42 PM, Henri Yandell > wrote: > > >> > > >> Having chatted around the 0mq community in the past; I've confidence > in > > >> their desire to move to MPL; and 26/32 committers is a great step > forward. > > >> You raise a good reservation though John - if you remove the blocker > on the > > >> usage side, it's easy for the licensing to remain as is. > > >> > > >> > > >> I'm +1 for releasing, with a prominent note of the LGPL dependency > (along > > >> with a note of the resolution plan). It might be that the Toree > committers > > >> may be motivated to rewrite code over at 0mq if there ends up being > any > > >> committers who are unavailable or unwilling to relicense. > > >> > > >> Hen > > >> > > >>> On Sat, Mar 5, 2016 at 3:45 PM, John D. Ament > > wrote: > > >>> > > >>> Sorry, misread the revision I was looking at. The intent to move to > MPL > > >>> was done on March 22 2014, 2 years ago this month, not December 2013. > > >>> > > >>> John > > >>> > > >>> On Sat, Mar 5, 2016 at 6:41 PM John D. Ament > > > >>> wrote: > > >>> > > >>>> I have some reservations with what you're proposing, and would like > you > > >>> to > > >>>> consult w/ legal-discuss on this first. > > >>>> > > >>>> There's a difference between what Mynewt did and what you're > proposing. > > >>>> Specifically, this was a transitive dependency that they relied upon > > >>>> indirectly, so its more of a call out for the library that was > leveraging > > >>>> it. They also intended to replace the library. > > >>>> > > >>>> In your case, you're directly tied to a presently LGPL'd library. > You > > >>>> have no intentions (from what I can see) of moving off of the > library. > > >>>> > > >>>> I'm also doubting their long term goals of moving to MPL. If you > look at > > >>>> [1], you'll see that the page hasn't been updated since October > 2014. In > > >>>> addition, looking at the pages revision history (the beauty of > wikis), > > >>> the > > >>>> intent to move to MPL was published in December 2013, making the > > >>> statement > > >>>> over 2 years old. > > >>>> > > >>>> I think while this might be OK for an initial incubator release, the > > >>>> project needs to weigh very heavily if it wants to continue to > leverage > > >>>> ZeroMQ or not going forward. > > >>>> > > >>>> [1]: http://zeromq.org/area:licensing > > >>>> > > >>>> > > >>>>> On Sat, Mar 5, 2016 at 5:06 PM Gino Bustelo > > > wrote: > > >>>>> > > >>>>> Wanted to give folks an update on our progress with dealing with > JeroMQ, > > >>>>> an > > >>>>> LGPL package that enables us to communicate via 0MQ. The 0MQ > community > > >>> is > > >>>>> very aware of the issues with LGPL (LGPLv3 + static link exception) > and > > >>> it > > >>>>> is their intention to try to move projects to MPL v2. This is not > an > > >>> easy > > >>>>> task depending on the age and size of the projects. > > >>>>> > > >>
Re: Update on Apache Toree and LGPL dependency
Just wanted to give a status update with this one. JeroMQ is down to just four contributors that have not responded. The current, active committers for JeroMQ have reverted the commits for one of the contributors here: https://github.com/zeromq/jeromq/pull/333 So, progress is still being made on this one! > +1 > > > On Mar 6, 2016, at 6:58 PM, Gino Bustelo wrote: > > > > @john The 0mq ecosystem is made up of many projects of different sizes and maturity. > In the case of JeroMQ, the committers are showing an overwhelming momentum to transition to > MPL. I don't see any reason for us to consider any other alternative at this juncture. > > > > Gino B. > > > >> On Mar 5, 2016, at 11:42 PM, Henri Yandell wrote: > >> > >> Having chatted around the 0mq community in the past; I've confidence in > >> their desire to move to MPL; and 26/32 committers is a great step forward. > >> You raise a good reservation though John - if you remove the blocker on the > >> usage side, it's easy for the licensing to remain as is. > >> > >> > >> I'm +1 for releasing, with a prominent note of the LGPL dependency (along > >> with a note of the resolution plan). It might be that the Toree committers > >> may be motivated to rewrite code over at 0mq if there ends up being any > >> committers who are unavailable or unwilling to relicense. > >> > >> Hen > >> > >>> On Sat, Mar 5, 2016 at 3:45 PM, John D. Ament wrote: > >>> > >>> Sorry, misread the revision I was looking at. The intent to move to MPL > >>> was done on March 22 2014, 2 years ago this month, not December 2013. > >>> > >>> John > >>> > >>> On Sat, Mar 5, 2016 at 6:41 PM John D. Ament > >>> wrote: > >>> > >>>> I have some reservations with what you're proposing, and would like you > >>> to > >>>> consult w/ legal-discuss on this first. > >>>> > >>>> There's a difference between what Mynewt did and what you're proposing. > >>>> Specifically, this was a transitive dependency that they relied upon > >>>> indirectly, so its more of a call out for the library that was leveraging > >>>> it. They also intended to replace the library. > >>>> > >>>> In your case, you're directly tied to a presently LGPL'd library. You > >>>> have no intentions (from what I can see) of moving off of the library. > >>>> > >>>> I'm also doubting their long term goals of moving to MPL. If you look at > >>>> [1], you'll see that the page hasn't been updated since October 2014. In > >>>> addition, looking at the pages revision history (the beauty of wikis), > >>> the > >>>> intent to move to MPL was published in December 2013, making the > >>> statement > >>>> over 2 years old. > >>>> > >>>> I think while this might be OK for an initial incubator release, the > >>>> project needs to weigh very heavily if it wants to continue to leverage > >>>> ZeroMQ or not going forward. > >>>> > >>>> [1]: http://zeromq.org/area:licensing > >>>> > >>>> > >>>>> On Sat, Mar 5, 2016 at 5:06 PM Gino Bustelo > wrote: > >>>>> > >>>>> Wanted to give folks an update on our progress with dealing with JeroMQ, > >>>>> an > >>>>> LGPL package that enables us to communicate via 0MQ. The 0MQ community > >>> is > >>>>> very aware of the issues with LGPL (LGPLv3 + static link exception) and > >>> it > >>>>> is their intention to try to move projects to MPL v2. This is not an > >>> easy > >>>>> task depending on the age and size of the projects. > >>>>> > >>>>> Apache Toree's API access point is through the 0MQ transport layer > >>> (using > >>>>> JeroMQ) and that is how Apache Toree connects out-of-the-box with > >>> Jupyter, > >>>>> a very common way of consuming Apache Toree that is already in > >>> production. > >>>>> > >>>>> At this point, the JeroMQ project is still released under LGPL, but our > >>>>> team initiated communications in mid-February with members of the JeroMQ > >>>>> community to begin their trans
Re: Update on Apache Toree and LGPL dependency
+1 > On Mar 6, 2016, at 6:58 PM, Gino Bustelo wrote: > > @john The 0mq ecosystem is made up of many projects of different sizes and > maturity. In the case of JeroMQ, the committers are showing an overwhelming > momentum to transition to MPL. I don't see any reason for us to consider any > other alternative at this juncture. > > Gino B. > >> On Mar 5, 2016, at 11:42 PM, Henri Yandell wrote: >> >> Having chatted around the 0mq community in the past; I've confidence in >> their desire to move to MPL; and 26/32 committers is a great step forward. >> You raise a good reservation though John - if you remove the blocker on the >> usage side, it's easy for the licensing to remain as is. >> >> >> I'm +1 for releasing, with a prominent note of the LGPL dependency (along >> with a note of the resolution plan). It might be that the Toree committers >> may be motivated to rewrite code over at 0mq if there ends up being any >> committers who are unavailable or unwilling to relicense. >> >> Hen >> >>> On Sat, Mar 5, 2016 at 3:45 PM, John D. Ament wrote: >>> >>> Sorry, misread the revision I was looking at. The intent to move to MPL >>> was done on March 22 2014, 2 years ago this month, not December 2013. >>> >>> John >>> >>> On Sat, Mar 5, 2016 at 6:41 PM John D. Ament >>> wrote: >>> >>>> I have some reservations with what you're proposing, and would like you >>> to >>>> consult w/ legal-discuss on this first. >>>> >>>> There's a difference between what Mynewt did and what you're proposing. >>>> Specifically, this was a transitive dependency that they relied upon >>>> indirectly, so its more of a call out for the library that was leveraging >>>> it. They also intended to replace the library. >>>> >>>> In your case, you're directly tied to a presently LGPL'd library. You >>>> have no intentions (from what I can see) of moving off of the library. >>>> >>>> I'm also doubting their long term goals of moving to MPL. If you look at >>>> [1], you'll see that the page hasn't been updated since October 2014. In >>>> addition, looking at the pages revision history (the beauty of wikis), >>> the >>>> intent to move to MPL was published in December 2013, making the >>> statement >>>> over 2 years old. >>>> >>>> I think while this might be OK for an initial incubator release, the >>>> project needs to weigh very heavily if it wants to continue to leverage >>>> ZeroMQ or not going forward. >>>> >>>> [1]: http://zeromq.org/area:licensing >>>> >>>> >>>>> On Sat, Mar 5, 2016 at 5:06 PM Gino Bustelo wrote: >>>>> >>>>> Wanted to give folks an update on our progress with dealing with JeroMQ, >>>>> an >>>>> LGPL package that enables us to communicate via 0MQ. The 0MQ community >>> is >>>>> very aware of the issues with LGPL (LGPLv3 + static link exception) and >>> it >>>>> is their intention to try to move projects to MPL v2. This is not an >>> easy >>>>> task depending on the age and size of the projects. >>>>> >>>>> Apache Toree's API access point is through the 0MQ transport layer >>> (using >>>>> JeroMQ) and that is how Apache Toree connects out-of-the-box with >>> Jupyter, >>>>> a very common way of consuming Apache Toree that is already in >>> production. >>>>> >>>>> At this point, the JeroMQ project is still released under LGPL, but our >>>>> team initiated communications in mid-February with members of the JeroMQ >>>>> community to begin their transition to MPL v2 ( >>>>> https://github.com/zeromq/jeromq/issues/326). The JeroMQ community >>>>> reacted >>>>> very positively and quickly began the process of collecting votes from >>>>> their committers (https://github.com/zeromq/jeromq/issues/327). After >>> 15 >>>>> days, the current tally stands at 26 out of 32 committers have agreed to >>>>> switch license. >>>>> >>>>> Apache Toree has a JIRA ( >>> https://issues.apache.org/jira/browse/TOREE-262) >>>>> where we keep all the relevant links and update with the latest >>>>> information. As that process is underway, we will move forward with >>> plans >>>>> to release a 0.1.0 version of Apache Toree based on the precedence set >>> by >>>>> Apache Mynewt ( >>> http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3C5F118AA0-4ADA-403B-A6EB-4A85F0B30651%40me.com%3E >>>>> ). >>>>> >>>>> Thanks, >>>>> Gino >>> > > - > 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: Update on Apache Toree and LGPL dependency
@john The 0mq ecosystem is made up of many projects of different sizes and maturity. In the case of JeroMQ, the committers are showing an overwhelming momentum to transition to MPL. I don't see any reason for us to consider any other alternative at this juncture. Gino B. > On Mar 5, 2016, at 11:42 PM, Henri Yandell wrote: > > Having chatted around the 0mq community in the past; I've confidence in > their desire to move to MPL; and 26/32 committers is a great step forward. > You raise a good reservation though John - if you remove the blocker on the > usage side, it's easy for the licensing to remain as is. > > > I'm +1 for releasing, with a prominent note of the LGPL dependency (along > with a note of the resolution plan). It might be that the Toree committers > may be motivated to rewrite code over at 0mq if there ends up being any > committers who are unavailable or unwilling to relicense. > > Hen > >> On Sat, Mar 5, 2016 at 3:45 PM, John D. Ament wrote: >> >> Sorry, misread the revision I was looking at. The intent to move to MPL >> was done on March 22 2014, 2 years ago this month, not December 2013. >> >> John >> >> On Sat, Mar 5, 2016 at 6:41 PM John D. Ament >> wrote: >> >>> I have some reservations with what you're proposing, and would like you >> to >>> consult w/ legal-discuss on this first. >>> >>> There's a difference between what Mynewt did and what you're proposing. >>> Specifically, this was a transitive dependency that they relied upon >>> indirectly, so its more of a call out for the library that was leveraging >>> it. They also intended to replace the library. >>> >>> In your case, you're directly tied to a presently LGPL'd library. You >>> have no intentions (from what I can see) of moving off of the library. >>> >>> I'm also doubting their long term goals of moving to MPL. If you look at >>> [1], you'll see that the page hasn't been updated since October 2014. In >>> addition, looking at the pages revision history (the beauty of wikis), >> the >>> intent to move to MPL was published in December 2013, making the >> statement >>> over 2 years old. >>> >>> I think while this might be OK for an initial incubator release, the >>> project needs to weigh very heavily if it wants to continue to leverage >>> ZeroMQ or not going forward. >>> >>> [1]: http://zeromq.org/area:licensing >>> >>> >>>> On Sat, Mar 5, 2016 at 5:06 PM Gino Bustelo wrote: >>>> >>>> Wanted to give folks an update on our progress with dealing with JeroMQ, >>>> an >>>> LGPL package that enables us to communicate via 0MQ. The 0MQ community >> is >>>> very aware of the issues with LGPL (LGPLv3 + static link exception) and >> it >>>> is their intention to try to move projects to MPL v2. This is not an >> easy >>>> task depending on the age and size of the projects. >>>> >>>> Apache Toree's API access point is through the 0MQ transport layer >> (using >>>> JeroMQ) and that is how Apache Toree connects out-of-the-box with >> Jupyter, >>>> a very common way of consuming Apache Toree that is already in >> production. >>>> >>>> At this point, the JeroMQ project is still released under LGPL, but our >>>> team initiated communications in mid-February with members of the JeroMQ >>>> community to begin their transition to MPL v2 ( >>>> https://github.com/zeromq/jeromq/issues/326). The JeroMQ community >>>> reacted >>>> very positively and quickly began the process of collecting votes from >>>> their committers (https://github.com/zeromq/jeromq/issues/327). After >> 15 >>>> days, the current tally stands at 26 out of 32 committers have agreed to >>>> switch license. >>>> >>>> Apache Toree has a JIRA ( >> https://issues.apache.org/jira/browse/TOREE-262) >>>> where we keep all the relevant links and update with the latest >>>> information. As that process is underway, we will move forward with >> plans >>>> to release a 0.1.0 version of Apache Toree based on the precedence set >> by >>>> Apache Mynewt ( >> http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3C5F118AA0-4ADA-403B-A6EB-4A85F0B30651%40me.com%3E >>>> ). >>>> >>>> Thanks, >>>> Gino >> - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Update on Apache Toree and LGPL dependency
Having chatted around the 0mq community in the past; I've confidence in their desire to move to MPL; and 26/32 committers is a great step forward. You raise a good reservation though John - if you remove the blocker on the usage side, it's easy for the licensing to remain as is. I'm +1 for releasing, with a prominent note of the LGPL dependency (along with a note of the resolution plan). It might be that the Toree committers may be motivated to rewrite code over at 0mq if there ends up being any committers who are unavailable or unwilling to relicense. Hen On Sat, Mar 5, 2016 at 3:45 PM, John D. Ament wrote: > Sorry, misread the revision I was looking at. The intent to move to MPL > was done on March 22 2014, 2 years ago this month, not December 2013. > > John > > On Sat, Mar 5, 2016 at 6:41 PM John D. Ament > wrote: > > > I have some reservations with what you're proposing, and would like you > to > > consult w/ legal-discuss on this first. > > > > There's a difference between what Mynewt did and what you're proposing. > > Specifically, this was a transitive dependency that they relied upon > > indirectly, so its more of a call out for the library that was leveraging > > it. They also intended to replace the library. > > > > In your case, you're directly tied to a presently LGPL'd library. You > > have no intentions (from what I can see) of moving off of the library. > > > > I'm also doubting their long term goals of moving to MPL. If you look at > > [1], you'll see that the page hasn't been updated since October 2014. In > > addition, looking at the pages revision history (the beauty of wikis), > the > > intent to move to MPL was published in December 2013, making the > statement > > over 2 years old. > > > > I think while this might be OK for an initial incubator release, the > > project needs to weigh very heavily if it wants to continue to leverage > > ZeroMQ or not going forward. > > > > [1]: http://zeromq.org/area:licensing > > > > > > On Sat, Mar 5, 2016 at 5:06 PM Gino Bustelo wrote: > > > >> Wanted to give folks an update on our progress with dealing with JeroMQ, > >> an > >> LGPL package that enables us to communicate via 0MQ. The 0MQ community > is > >> very aware of the issues with LGPL (LGPLv3 + static link exception) and > it > >> is their intention to try to move projects to MPL v2. This is not an > easy > >> task depending on the age and size of the projects. > >> > >> Apache Toree's API access point is through the 0MQ transport layer > (using > >> JeroMQ) and that is how Apache Toree connects out-of-the-box with > Jupyter, > >> a very common way of consuming Apache Toree that is already in > production. > >> > >> At this point, the JeroMQ project is still released under LGPL, but our > >> team initiated communications in mid-February with members of the JeroMQ > >> community to begin their transition to MPL v2 ( > >> https://github.com/zeromq/jeromq/issues/326). The JeroMQ community > >> reacted > >> very positively and quickly began the process of collecting votes from > >> their committers (https://github.com/zeromq/jeromq/issues/327). After > 15 > >> days, the current tally stands at 26 out of 32 committers have agreed to > >> switch license. > >> > >> Apache Toree has a JIRA ( > https://issues.apache.org/jira/browse/TOREE-262) > >> where we keep all the relevant links and update with the latest > >> information. As that process is underway, we will move forward with > plans > >> to release a 0.1.0 version of Apache Toree based on the precedence set > by > >> Apache Mynewt ( > >> > >> > http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3C5F118AA0-4ADA-403B-A6EB-4A85F0B30651%40me.com%3E > >> ). > >> > >> Thanks, > >> Gino > >> > > >
Re: Update on Apache Toree and LGPL dependency
Sorry, misread the revision I was looking at. The intent to move to MPL was done on March 22 2014, 2 years ago this month, not December 2013. John On Sat, Mar 5, 2016 at 6:41 PM John D. Ament wrote: > I have some reservations with what you're proposing, and would like you to > consult w/ legal-discuss on this first. > > There's a difference between what Mynewt did and what you're proposing. > Specifically, this was a transitive dependency that they relied upon > indirectly, so its more of a call out for the library that was leveraging > it. They also intended to replace the library. > > In your case, you're directly tied to a presently LGPL'd library. You > have no intentions (from what I can see) of moving off of the library. > > I'm also doubting their long term goals of moving to MPL. If you look at > [1], you'll see that the page hasn't been updated since October 2014. In > addition, looking at the pages revision history (the beauty of wikis), the > intent to move to MPL was published in December 2013, making the statement > over 2 years old. > > I think while this might be OK for an initial incubator release, the > project needs to weigh very heavily if it wants to continue to leverage > ZeroMQ or not going forward. > > [1]: http://zeromq.org/area:licensing > > > On Sat, Mar 5, 2016 at 5:06 PM Gino Bustelo wrote: > >> Wanted to give folks an update on our progress with dealing with JeroMQ, >> an >> LGPL package that enables us to communicate via 0MQ. The 0MQ community is >> very aware of the issues with LGPL (LGPLv3 + static link exception) and it >> is their intention to try to move projects to MPL v2. This is not an easy >> task depending on the age and size of the projects. >> >> Apache Toree's API access point is through the 0MQ transport layer (using >> JeroMQ) and that is how Apache Toree connects out-of-the-box with Jupyter, >> a very common way of consuming Apache Toree that is already in production. >> >> At this point, the JeroMQ project is still released under LGPL, but our >> team initiated communications in mid-February with members of the JeroMQ >> community to begin their transition to MPL v2 ( >> https://github.com/zeromq/jeromq/issues/326). The JeroMQ community >> reacted >> very positively and quickly began the process of collecting votes from >> their committers (https://github.com/zeromq/jeromq/issues/327). After 15 >> days, the current tally stands at 26 out of 32 committers have agreed to >> switch license. >> >> Apache Toree has a JIRA (https://issues.apache.org/jira/browse/TOREE-262) >> where we keep all the relevant links and update with the latest >> information. As that process is underway, we will move forward with plans >> to release a 0.1.0 version of Apache Toree based on the precedence set by >> Apache Mynewt ( >> >> http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3C5F118AA0-4ADA-403B-A6EB-4A85F0B30651%40me.com%3E >> ). >> >> Thanks, >> Gino >> >
Re: Update on Apache Toree and LGPL dependency
I have some reservations with what you're proposing, and would like you to consult w/ legal-discuss on this first. There's a difference between what Mynewt did and what you're proposing. Specifically, this was a transitive dependency that they relied upon indirectly, so its more of a call out for the library that was leveraging it. They also intended to replace the library. In your case, you're directly tied to a presently LGPL'd library. You have no intentions (from what I can see) of moving off of the library. I'm also doubting their long term goals of moving to MPL. If you look at [1], you'll see that the page hasn't been updated since October 2014. In addition, looking at the pages revision history (the beauty of wikis), the intent to move to MPL was published in December 2013, making the statement over 2 years old. I think while this might be OK for an initial incubator release, the project needs to weigh very heavily if it wants to continue to leverage ZeroMQ or not going forward. [1]: http://zeromq.org/area:licensing On Sat, Mar 5, 2016 at 5:06 PM Gino Bustelo wrote: > Wanted to give folks an update on our progress with dealing with JeroMQ, an > LGPL package that enables us to communicate via 0MQ. The 0MQ community is > very aware of the issues with LGPL (LGPLv3 + static link exception) and it > is their intention to try to move projects to MPL v2. This is not an easy > task depending on the age and size of the projects. > > Apache Toree's API access point is through the 0MQ transport layer (using > JeroMQ) and that is how Apache Toree connects out-of-the-box with Jupyter, > a very common way of consuming Apache Toree that is already in production. > > At this point, the JeroMQ project is still released under LGPL, but our > team initiated communications in mid-February with members of the JeroMQ > community to begin their transition to MPL v2 ( > https://github.com/zeromq/jeromq/issues/326). The JeroMQ community reacted > very positively and quickly began the process of collecting votes from > their committers (https://github.com/zeromq/jeromq/issues/327). After 15 > days, the current tally stands at 26 out of 32 committers have agreed to > switch license. > > Apache Toree has a JIRA (https://issues.apache.org/jira/browse/TOREE-262) > where we keep all the relevant links and update with the latest > information. As that process is underway, we will move forward with plans > to release a 0.1.0 version of Apache Toree based on the precedence set by > Apache Mynewt ( > > http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3C5F118AA0-4ADA-403B-A6EB-4A85F0B30651%40me.com%3E > ). > > Thanks, > Gino >
Update on Apache Toree and LGPL dependency
Wanted to give folks an update on our progress with dealing with JeroMQ, an LGPL package that enables us to communicate via 0MQ. The 0MQ community is very aware of the issues with LGPL (LGPLv3 + static link exception) and it is their intention to try to move projects to MPL v2. This is not an easy task depending on the age and size of the projects. Apache Toree's API access point is through the 0MQ transport layer (using JeroMQ) and that is how Apache Toree connects out-of-the-box with Jupyter, a very common way of consuming Apache Toree that is already in production. At this point, the JeroMQ project is still released under LGPL, but our team initiated communications in mid-February with members of the JeroMQ community to begin their transition to MPL v2 ( https://github.com/zeromq/jeromq/issues/326). The JeroMQ community reacted very positively and quickly began the process of collecting votes from their committers (https://github.com/zeromq/jeromq/issues/327). After 15 days, the current tally stands at 26 out of 32 committers have agreed to switch license. Apache Toree has a JIRA (https://issues.apache.org/jira/browse/TOREE-262) where we keep all the relevant links and update with the latest information. As that process is underway, we will move forward with plans to release a 0.1.0 version of Apache Toree based on the precedence set by Apache Mynewt ( http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3C5F118AA0-4ADA-403B-A6EB-4A85F0B30651%40me.com%3E ). Thanks, Gino
Re: Update on Apache Toree and LGPL dependency
Thanks @stian. I was trying to sell them on the bigger picture that being able to consume 0MQ within Apache projects would increase their user base. On Fri, Mar 4, 2016 at 11:13 AM, Stian Soiland-Reyes wrote: > I know software licensing can be a difficult thing to investigate, not > to mention change! > > So very well done for managing to influence another open source > project! Apache projects don't live in isolation, and participating > in the wider community is also an important aspect of open > development. > > I guess this might also be a good opportunity to promote Apache Toree > within 0MQ community :) > > > On 3 March 2016 at 14:58, Gino Bustelo wrote: > > Wanted to give folks an update on our progress with dealing with JeroMQ, > an > > LGPL package that enables us to communicate via 0MQ. The 0MQ community is > > very aware of the issues with LGPL (LGPLv3 + static link exception) and > it > > is their intention to try to move projects to MPL v2. This is not an easy > > task depending on the age and size of the projects. > > > > Apache Toree's API access point is through the 0MQ transport layer (using > > JeroMQ) and that is how Apache Toree connects out-of-the-box with > Jupyter, > > a very common way of consuming Apache Toree that is already in > production. > > > > At this point, the JeroMQ project is still released under LGPL, but our > > team initiated communications in mid-February with members of the JeroMQ > > community to begin their transition to MPL v2 ( > > https://github.com/zeromq/jeromq/issues/326). The JeroMQ community > reacted > > very positively and quickly began the process of collecting votes from > > their committers (https://github.com/zeromq/jeromq/issues/327). After 15 > > days, the current tally stands at 26 out of 32 committers have agreed to > > switch license. > > > > Apache Toree has a JIRA (https://issues.apache.org/jira/browse/TOREE-262 > ) > > where we keep all the relevant links and update with the latest > > information. As that process is underway, we will move forward with plans > > to release a 0.1.0 version of Apache Toree based on the precedence set by > > Apache Mynewt ( > > > http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3C5F118AA0-4ADA-403B-A6EB-4A85F0B30651%40me.com%3E > > ). > > > > Thanks, > > Gino > > > > -- > Stian Soiland-Reyes > Apache Taverna (incubating), Apache Commons RDF (incubating) > http://orcid.org/-0001-9842-9718 > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: Update on Apache Toree and LGPL dependency
I know software licensing can be a difficult thing to investigate, not to mention change! So very well done for managing to influence another open source project! Apache projects don't live in isolation, and participating in the wider community is also an important aspect of open development. I guess this might also be a good opportunity to promote Apache Toree within 0MQ community :) On 3 March 2016 at 14:58, Gino Bustelo wrote: > Wanted to give folks an update on our progress with dealing with JeroMQ, an > LGPL package that enables us to communicate via 0MQ. The 0MQ community is > very aware of the issues with LGPL (LGPLv3 + static link exception) and it > is their intention to try to move projects to MPL v2. This is not an easy > task depending on the age and size of the projects. > > Apache Toree's API access point is through the 0MQ transport layer (using > JeroMQ) and that is how Apache Toree connects out-of-the-box with Jupyter, > a very common way of consuming Apache Toree that is already in production. > > At this point, the JeroMQ project is still released under LGPL, but our > team initiated communications in mid-February with members of the JeroMQ > community to begin their transition to MPL v2 ( > https://github.com/zeromq/jeromq/issues/326). The JeroMQ community reacted > very positively and quickly began the process of collecting votes from > their committers (https://github.com/zeromq/jeromq/issues/327). After 15 > days, the current tally stands at 26 out of 32 committers have agreed to > switch license. > > Apache Toree has a JIRA (https://issues.apache.org/jira/browse/TOREE-262) > where we keep all the relevant links and update with the latest > information. As that process is underway, we will move forward with plans > to release a 0.1.0 version of Apache Toree based on the precedence set by > Apache Mynewt ( > http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3C5F118AA0-4ADA-403B-A6EB-4A85F0B30651%40me.com%3E > ). > > Thanks, > Gino -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons RDF (incubating) http://orcid.org/-0001-9842-9718 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Update on Apache Toree and LGPL dependency
Wanted to give folks an update on our progress with dealing with JeroMQ, an LGPL package that enables us to communicate via 0MQ. The 0MQ community is very aware of the issues with LGPL (LGPLv3 + static link exception) and it is their intention to try to move projects to MPL v2. This is not an easy task depending on the age and size of the projects. Apache Toree's API access point is through the 0MQ transport layer (using JeroMQ) and that is how Apache Toree connects out-of-the-box with Jupyter, a very common way of consuming Apache Toree that is already in production. At this point, the JeroMQ project is still released under LGPL, but our team initiated communications in mid-February with members of the JeroMQ community to begin their transition to MPL v2 ( https://github.com/zeromq/jeromq/issues/326). The JeroMQ community reacted very positively and quickly began the process of collecting votes from their committers (https://github.com/zeromq/jeromq/issues/327). After 15 days, the current tally stands at 26 out of 32 committers have agreed to switch license. Apache Toree has a JIRA (https://issues.apache.org/jira/browse/TOREE-262) where we keep all the relevant links and update with the latest information. As that process is underway, we will move forward with plans to release a 0.1.0 version of Apache Toree based on the precedence set by Apache Mynewt ( http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3C5F118AA0-4ADA-403B-A6EB-4A85F0B30651%40me.com%3E ). Thanks, Gino