Re: Request for Temporary Exception for LGPL Dependency in Apache KIE Podling

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

Re: Request for Temporary Exception for LGPL Dependency in Apache KIE Podling

gt; 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 secur

Re: Request for Temporary Exception for LGPL Dependency in Apache KIE Podling

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 t

Re: Request for Temporary Exception for LGPL Dependency in Apache KIE Podling

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

Re: Request for Temporary Exception for LGPL Dependency in Apache KIE Podling

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

Request for Temporary Exception for LGPL Dependency in Apache KIE Podling

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

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

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

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 >

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

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

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 >

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,

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日周二

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

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

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

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

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

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

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

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

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

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

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

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

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

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 *

Re: LGPL dependency

nvenience 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: LGPL dependency

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

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

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

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

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

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

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

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

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

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

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

Re: Update on Apache Toree and LGPL dependency

; 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. > > >> &g

Re: Update on Apache Toree and LGPL dependency

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

Re: Update on Apache Toree and LGPL dependency

re 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

Re: Update on Apache Toree and LGPL dependency

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

Re: Update on Apache Toree and LGPL dependency

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

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

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

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

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,

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

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