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

[Jason Porter]

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

[Alex Porcelli]

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/
> > > > [2]

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

[tison]

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

[Alex Porcelli]

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

[PJ Fanning]

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

[Alex Porcelli]

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

[York Shen]

Thanks for your supporting.

I will bring it to general@incubator when vote passed in weex@dev

Best Regards,
York Shen

申远

> 在 2019年7月2日，15:20，Myrle Krantz  写道：
> 
> Hey Jim,
> 
> Thank you for asking.  : o)  Weex is still cutting the release.  It's
> precisely because this can be time-consuming that they asked before they
> started.  They'll bring it for a vote once they have it.
> 
> Best,
> Myrle
> 
> On Mon, Jul 1, 2019 at 6:19 PM Jim Jagielski  wrote:
> 
>> Myrle, did you get all you needed? Enough votes and all to get the release
>> unblocked?
>> 
>>> On Jun 28, 2019, at 11:24 AM, Myrle Krantz  wrote:
>>> 
>>> I've said it on dev@weex, and on private@incubator, but I wanted to make
>>> sure and say it here too.  Weex should cut the release.  We'll figure out
>>> the rest later.  The straw poll on private@incubator also confirms: you
>>> have my support and the support of many of the mentors in the
>> incubator.  I
>>> apologize for us blocking you for so long.
>>> 
>>> Best Regards,
>>> Myrle Krantz
>>> PMC Member, Apache Incubator
>>> 
>>> On Thu, Jun 27, 2019 at 6:06 AM 申远  wrote:
>>> 
 It looks like we have got result[1] from Legal VP, I will bring it here
>> now
 
  1. It's fine if Weex only could include header files under 2-clause
>> BSD
  license from Webkit at compiling time and has a dynamic link to
 Webkit.so
  at runtime.
  2. It's recommended that excluding Webkit.so from Weex convenience
  library. Users would include the code snippet below to include both
>> weex
  and webkit.
 
 
 
   weex_sdk
 
 
 
 
 
   webkit
 
 
 
 
 The following is what I need to consult from Incubator:
 
 Google will ban all apps without 64 bit published in Google Play from
>> 1st,
 August, 2019 [1]. Though it's a good idea of excluding Webkit.so from
 convenience library of Weex, Weex community needs to publish next
>> release
 with 64-bit support ASAP to give users enough time to upgrade Weex. I'd
 like to remain webkit.so in convenience library of Weex only for next
 release.
 
 [1] https://issues.apache.org/jira/browse/LEGAL-464
 [2]
>> https://developer.android.com/distribute/best-practices/develop/64-bit
 
 Best Regards,
 YorkShen
 
 申远
 
 
 Roman Shaposhnik  于2019年6月24日周一 上午7:32写道：
 
> Lets continue this discussion on
> https://issues.apache.org/jira/browse/LEGAL-464 please
> 
> On Sat, Jun 22, 2019 at 2:18 PM Matt Sicker  wrote:
>> 
>> WebKit dates back to KHTML, an LGPL web engine from KDE. It sounds
>> like
>> it’s some WebKit specific files that are BSD licensed. I haven’t
> inspected
>> the individual files, but I suspect that the header files are BSD
> licensed
>> to make linking less of a legal headache.
>> 
>> On Sat, Jun 22, 2019 at 07:11, Craig Russell 
> wrote:
>> 
>>> The Webkit license page https://webkit.org/licensing-webkit/ says
>>> portions licensed under LGPL and BSD licenses.
>>> 
>>> Usually this means it's the user's choice which license to use.
>>> 
>>> We would choose the BSD License for the components that we use.
>>> 
>>> Can you find anywhere a statement that the Webkit.so is licensed only
>>> under LGPL?
>>> 
>>> Craig
>>> 
 On Jun 14, 2019, at 1:40 AM, 申远  wrote:
 
 As mentioned above, Webkit is under dual License(BSD and LPGL) and
> it's
 almost impossible for us to figure out which function is a pure BSD
 function. I don't know
 Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL will
 happen
> or
 not. Perhaps pure BSD header file will lead to pure BSD
> implementation.
 Perhaps?
 
 As for alternative dependency, it's possible if we make some major
>>> changes
 to Weex. But convenience binary of each Weex release includes
> Webkit.so,
 how to solve that problem? Maybe publish two convenience binary,
 one
>>> named
 Weex_WebKit.aar and the other named Weex_BSDKit.aar ? Not sounds
> like a
 good idea to me.
 
 Best Regards,
 YorkShen
 
 申远
 
 
 Sheng Wu  于2019年6月14日周五 下午4:23写道：
 
> Hi York
> 
> I am not a C/C++ coder, so I could be wrong.
> 
> But from I saw, Catalog X dependency required is not right. Like
 Hen
>>> said,
> alternative is an option.
> 
> Such as
> Today’s another incubating project, ShardingSphere.
> When user wants to MySQL sharing, then they needs to accept MySQL
> Driver
> license first(or already accepted).
> But user could use ShardingSphere with PostgreSQL JDBC Driver.
> 
> 
> Sheng Wu
> Apache Skywalking, 

Re: LGPL dependency

[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, ShardingSphere, Zipkin
> >>>
> >>>
> >>>
>  在 2019年6月14日，下午4:15，Hen  写道：
> 
>  Assuming Weex requires Webkit and is unable to work with an
> > alternative,
>  the issue here is that users of Weex 

Re: LGPL dependency

[Jim Jagielski]

Myrle, did you get all you needed? Enough votes and all to get the release 
unblocked?

> On Jun 28, 2019, at 11:24 AM, Myrle Krantz  wrote:
> 
> I've said it on dev@weex, and on private@incubator, but I wanted to make
> sure and say it here too.  Weex should cut the release.  We'll figure out
> the rest later.  The straw poll on private@incubator also confirms: you
> have my support and the support of many of the mentors in the incubator.  I
> apologize for us blocking you for so long.
> 
> Best Regards,
> Myrle Krantz
> PMC Member, Apache Incubator
> 
> On Thu, Jun 27, 2019 at 6:06 AM 申远  wrote:
> 
>> It looks like we have got result[1] from Legal VP, I will bring it here now
>> 
>>   1. It's fine if Weex only could include header files under 2-clause BSD
>>   license from Webkit at compiling time and has a dynamic link to
>> Webkit.so
>>   at runtime.
>>   2. It's recommended that excluding Webkit.so from Weex convenience
>>   library. Users would include the code snippet below to include both weex
>>   and webkit.
>> 
>> 
>> 
>>weex_sdk
>> 
>> 
>> 
>> 
>> 
>>webkit
>> 
>> 
>> 
>> 
>> The following is what I need to consult from Incubator:
>> 
>> Google will ban all apps without 64 bit published in Google Play from 1st,
>> August, 2019 [1]. Though it's a good idea of excluding Webkit.so from
>> convenience library of Weex, Weex community needs to publish next release
>> with 64-bit support ASAP to give users enough time to upgrade Weex. I'd
>> like to remain webkit.so in convenience library of Weex only for next
>> release.
>> 
>> [1] https://issues.apache.org/jira/browse/LEGAL-464
>> [2] https://developer.android.com/distribute/best-practices/develop/64-bit
>> 
>> Best Regards,
>> YorkShen
>> 
>> 申远
>> 
>> 
>> Roman Shaposhnik  于2019年6月24日周一 上午7:32写道：
>> 
>>> Lets continue this discussion on
>>> https://issues.apache.org/jira/browse/LEGAL-464 please
>>> 
>>> On Sat, Jun 22, 2019 at 2:18 PM Matt Sicker  wrote:
 
 WebKit dates back to KHTML, an LGPL web engine from KDE. It sounds like
 it’s some WebKit specific files that are BSD licensed. I haven’t
>>> inspected
 the individual files, but I suspect that the header files are BSD
>>> licensed
 to make linking less of a legal headache.
 
 On Sat, Jun 22, 2019 at 07:11, Craig Russell 
>>> wrote:
 
> The Webkit license page https://webkit.org/licensing-webkit/ says
> portions licensed under LGPL and BSD licenses.
> 
> Usually this means it's the user's choice which license to use.
> 
> We would choose the BSD License for the components that we use.
> 
> Can you find anywhere a statement that the Webkit.so is licensed only
> under LGPL?
> 
> Craig
> 
>> On Jun 14, 2019, at 1:40 AM, 申远  wrote:
>> 
>> As mentioned above, Webkit is under dual License(BSD and LPGL) and
>>> it's
>> almost impossible for us to figure out which function is a pure BSD
>> function. I don't know
>> Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL will
>> happen
>>> or
>> not. Perhaps pure BSD header file will lead to pure BSD
>>> implementation.
>> Perhaps?
>> 
>> As for alternative dependency, it's possible if we make some major
> changes
>> to Weex. But convenience binary of each Weex release includes
>>> Webkit.so,
>> how to solve that problem? Maybe publish two convenience binary,
>> one
> named
>> Weex_WebKit.aar and the other named Weex_BSDKit.aar ? Not sounds
>>> like a
>> good idea to me.
>> 
>> Best Regards,
>> YorkShen
>> 
>> 申远
>> 
>> 
>> Sheng Wu  于2019年6月14日周五 下午4:23写道：
>> 
>>> Hi York
>>> 
>>> I am not a C/C++ coder, so I could be wrong.
>>> 
>>> But from I saw, Catalog X dependency required is not right. Like
>> Hen
> said,
>>> alternative is an option.
>>> 
>>> Such as
>>> Today’s another incubating project, ShardingSphere.
>>> When user wants to MySQL sharing, then they needs to accept MySQL
>>> Driver
>>> license first(or already accepted).
>>> But user could use ShardingSphere with PostgreSQL JDBC Driver.
>>> 
>>> 
>>> Sheng Wu
>>> Apache Skywalking, ShardingSphere, Zipkin
>>> 
>>> 
>>> 
 在 2019年6月14日，下午4:15，Hen  写道：
 
 Assuming Weex requires Webkit and is unable to work with an
> alternative,
 the issue here is that users of Weex would seem to have to permit
> reverse
 engineering in their legal terms. Our position has been that that
>>> goes
 beyond the scope of the Apache 2.0 license and would be an
>>> unpleasant
 surprise for users.
 
 (seem to have to  =>  this is how we've discussed the license; an
> actual
 court may decide something completely different)
 
 Looking at Weex's website's description, it does not seem to be
>>> that a
>>> user
 of Weex will already have 

Re: LGPL dependency

[Myrle Krantz]

I've said it on dev@weex, and on private@incubator, but I wanted to make
sure and say it here too.  Weex should cut the release.  We'll figure out
the rest later.  The straw poll on private@incubator also confirms: you
have my support and the support of many of the mentors in the incubator.  I
apologize for us blocking you for so long.

Best Regards,
Myrle Krantz
PMC Member, Apache Incubator

On Thu, Jun 27, 2019 at 6:06 AM 申远  wrote:

> It looks like we have got result[1] from Legal VP, I will bring it here now
>
>1. It's fine if Weex only could include header files under 2-clause BSD
>license from Webkit at compiling time and has a dynamic link to
> Webkit.so
>at runtime.
>2. It's recommended that excluding Webkit.so from Weex convenience
>library. Users would include the code snippet below to include both weex
>and webkit.
>
> 
>
> weex_sdk
>
> 
>
> 
>
> webkit
>
> 
>
>
> The following is what I need to consult from Incubator:
>
> Google will ban all apps without 64 bit published in Google Play from 1st,
> August, 2019 [1]. Though it's a good idea of excluding Webkit.so from
> convenience library of Weex, Weex community needs to publish next release
> with 64-bit support ASAP to give users enough time to upgrade Weex. I'd
> like to remain webkit.so in convenience library of Weex only for next
> release.
>
> [1] https://issues.apache.org/jira/browse/LEGAL-464
> [2] https://developer.android.com/distribute/best-practices/develop/64-bit
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> Roman Shaposhnik  于2019年6月24日周一 上午7:32写道：
>
> > Lets continue this discussion on
> > https://issues.apache.org/jira/browse/LEGAL-464 please
> >
> > On Sat, Jun 22, 2019 at 2:18 PM Matt Sicker  wrote:
> > >
> > > WebKit dates back to KHTML, an LGPL web engine from KDE. It sounds like
> > > it’s some WebKit specific files that are BSD licensed. I haven’t
> > inspected
> > > the individual files, but I suspect that the header files are BSD
> > licensed
> > > to make linking less of a legal headache.
> > >
> > > On Sat, Jun 22, 2019 at 07:11, Craig Russell 
> > wrote:
> > >
> > > > The Webkit license page https://webkit.org/licensing-webkit/ says
> > > > portions licensed under LGPL and BSD licenses.
> > > >
> > > > Usually this means it's the user's choice which license to use.
> > > >
> > > > We would choose the BSD License for the components that we use.
> > > >
> > > > Can you find anywhere a statement that the Webkit.so is licensed only
> > > > under LGPL?
> > > >
> > > > Craig
> > > >
> > > > > On Jun 14, 2019, at 1:40 AM, 申远  wrote:
> > > > >
> > > > > As mentioned above, Webkit is under dual License(BSD and LPGL) and
> > it's
> > > > > almost impossible for us to figure out which function is a pure BSD
> > > > > function. I don't know
> > > > > Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL will
> happen
> > or
> > > > > not. Perhaps pure BSD header file will lead to pure BSD
> > implementation.
> > > > > Perhaps?
> > > > >
> > > > > As for alternative dependency, it's possible if we make some major
> > > > changes
> > > > > to Weex. But convenience binary of each Weex release includes
> > Webkit.so,
> > > > > how to solve that problem? Maybe publish two convenience binary,
> one
> > > > named
> > > > > Weex_WebKit.aar and the other named Weex_BSDKit.aar ? Not sounds
> > like a
> > > > > good idea to me.
> > > > >
> > > > > Best Regards,
> > > > > YorkShen
> > > > >
> > > > > 申远
> > > > >
> > > > >
> > > > > Sheng Wu  于2019年6月14日周五 下午4:23写道：
> > > > >
> > > > >> Hi York
> > > > >>
> > > > >> I am not a C/C++ coder, so I could be wrong.
> > > > >>
> > > > >> But from I saw, Catalog X dependency required is not right. Like
> Hen
> > > > said,
> > > > >> alternative is an option.
> > > > >>
> > > > >> Such as
> > > > >> Today’s another incubating project, ShardingSphere.
> > > > >> When user wants to MySQL sharing, then they needs to accept MySQL
> > Driver
> > > > >> license first(or already accepted).
> > > > >> But user could use ShardingSphere with PostgreSQL JDBC Driver.
> > > > >>
> > > > >>
> > > > >> Sheng Wu
> > > > >> Apache Skywalking, ShardingSphere, Zipkin
> > > > >>
> > > > >>
> > > > >>
> > > > >>> 在 2019年6月14日，下午4:15，Hen  写道：
> > > > >>>
> > > > >>> Assuming Weex requires Webkit and is unable to work with an
> > > > alternative,
> > > > >>> the issue here is that users of Weex would seem to have to permit
> > > > reverse
> > > > >>> engineering in their legal terms. Our position has been that that
> > goes
> > > > >>> beyond the scope of the Apache 2.0 license and would be an
> > unpleasant
> > > > >>> surprise for users.
> > > > >>>
> > > > >>> (seem to have to  =>  this is how we've discussed the license; an
> > > > actual
> > > > >>> court may decide something completely different)
> > > > >>>
> > > > >>> Looking at Weex's website's description, it does not seem to be
> > that a
> > > > >> user
> > > > >>> of Weex will already have agreed to the terms of Webkit; thus I
> 

Re: LGPL dependency

[申远]

It looks like we have got result[1] from Legal VP, I will bring it here now

   1. It's fine if Weex only could include header files under 2-clause BSD
   license from Webkit at compiling time and has a dynamic link to Webkit.so
   at runtime.
   2. It's recommended that excluding Webkit.so from Weex convenience
   library. Users would include the code snippet below to include both weex
   and webkit.



weex_sdk





webkit




The following is what I need to consult from Incubator:

Google will ban all apps without 64 bit published in Google Play from 1st,
August, 2019 [1]. Though it's a good idea of excluding Webkit.so from
convenience library of Weex, Weex community needs to publish next release
with 64-bit support ASAP to give users enough time to upgrade Weex. I'd
like to remain webkit.so in convenience library of Weex only for next
release.

[1] https://issues.apache.org/jira/browse/LEGAL-464
[2] https://developer.android.com/distribute/best-practices/develop/64-bit

Best Regards,
YorkShen

申远


Roman Shaposhnik  于2019年6月24日周一 上午7:32写道：

> Lets continue this discussion on
> https://issues.apache.org/jira/browse/LEGAL-464 please
>
> On Sat, Jun 22, 2019 at 2:18 PM Matt Sicker  wrote:
> >
> > WebKit dates back to KHTML, an LGPL web engine from KDE. It sounds like
> > it’s some WebKit specific files that are BSD licensed. I haven’t
> inspected
> > the individual files, but I suspect that the header files are BSD
> licensed
> > to make linking less of a legal headache.
> >
> > On Sat, Jun 22, 2019 at 07:11, Craig Russell 
> wrote:
> >
> > > The Webkit license page https://webkit.org/licensing-webkit/ says
> > > portions licensed under LGPL and BSD licenses.
> > >
> > > Usually this means it's the user's choice which license to use.
> > >
> > > We would choose the BSD License for the components that we use.
> > >
> > > Can you find anywhere a statement that the Webkit.so is licensed only
> > > under LGPL?
> > >
> > > Craig
> > >
> > > > On Jun 14, 2019, at 1:40 AM, 申远  wrote:
> > > >
> > > > As mentioned above, Webkit is under dual License(BSD and LPGL) and
> it's
> > > > almost impossible for us to figure out which function is a pure BSD
> > > > function. I don't know
> > > > Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL will happen
> or
> > > > not. Perhaps pure BSD header file will lead to pure BSD
> implementation.
> > > > Perhaps?
> > > >
> > > > As for alternative dependency, it's possible if we make some major
> > > changes
> > > > to Weex. But convenience binary of each Weex release includes
> Webkit.so,
> > > > how to solve that problem? Maybe publish two convenience binary, one
> > > named
> > > > Weex_WebKit.aar and the other named Weex_BSDKit.aar ? Not sounds
> like a
> > > > good idea to me.
> > > >
> > > > Best Regards,
> > > > YorkShen
> > > >
> > > > 申远
> > > >
> > > >
> > > > Sheng Wu  于2019年6月14日周五 下午4:23写道：
> > > >
> > > >> Hi York
> > > >>
> > > >> I am not a C/C++ coder, so I could be wrong.
> > > >>
> > > >> But from I saw, Catalog X dependency required is not right. Like Hen
> > > said,
> > > >> alternative is an option.
> > > >>
> > > >> Such as
> > > >> Today’s another incubating project, ShardingSphere.
> > > >> When user wants to MySQL sharing, then they needs to accept MySQL
> Driver
> > > >> license first(or already accepted).
> > > >> But user could use ShardingSphere with PostgreSQL JDBC Driver.
> > > >>
> > > >>
> > > >> Sheng Wu
> > > >> Apache Skywalking, ShardingSphere, Zipkin
> > > >>
> > > >>
> > > >>
> > > >>> 在 2019年6月14日，下午4:15，Hen  写道：
> > > >>>
> > > >>> Assuming Weex requires Webkit and is unable to work with an
> > > alternative,
> > > >>> the issue here is that users of Weex would seem to have to permit
> > > reverse
> > > >>> engineering in their legal terms. Our position has been that that
> goes
> > > >>> beyond the scope of the Apache 2.0 license and would be an
> unpleasant
> > > >>> surprise for users.
> > > >>>
> > > >>> (seem to have to  =>  this is how we've discussed the license; an
> > > actual
> > > >>> court may decide something completely different)
> > > >>>
> > > >>> Looking at Weex's website's description, it does not seem to be
> that a
> > > >> user
> > > >>> of Weex will already have agreed to the terms of Webkit; thus I
> believe
> > > >>> they would be unpleasantly surprised.
> > > >>>
> > > >>> Hen
> > > >>>
> > > >>> On Fri, Jun 14, 2019 at 12:49 AM 申远  wrote:
> > > >>>
> > >  Hi,
> > > 
> > >  I am a PPMC member of Apache Weex. After serious reviewing of our
> > >  dependencies, I found there some of the source code we copied from
> > > >> Webkit
> > >  is actually under LGPL license(Category X) and our license format
> > > tools
> > >  changed the license header of these files to Apache v2
> incorrectly.
> > > I'd
> > >  like to hear advice from incubator that whether our actions below
> > > would
> > > >> fix
> > >  the Category X issue.
> > > 
> > >  First of all, License 

Re: LGPL dependency

[Roman Shaposhnik]

Lets continue this discussion on
https://issues.apache.org/jira/browse/LEGAL-464 please

On Sat, Jun 22, 2019 at 2:18 PM Matt Sicker  wrote:
>
> WebKit dates back to KHTML, an LGPL web engine from KDE. It sounds like
> it’s some WebKit specific files that are BSD licensed. I haven’t inspected
> the individual files, but I suspect that the header files are BSD licensed
> to make linking less of a legal headache.
>
> On Sat, Jun 22, 2019 at 07:11, Craig Russell  wrote:
>
> > The Webkit license page https://webkit.org/licensing-webkit/ says
> > portions licensed under LGPL and BSD licenses.
> >
> > Usually this means it's the user's choice which license to use.
> >
> > We would choose the BSD License for the components that we use.
> >
> > Can you find anywhere a statement that the Webkit.so is licensed only
> > under LGPL?
> >
> > Craig
> >
> > > On Jun 14, 2019, at 1:40 AM, 申远  wrote:
> > >
> > > As mentioned above, Webkit is under dual License(BSD and LPGL) and it's
> > > almost impossible for us to figure out which function is a pure BSD
> > > function. I don't know
> > > Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL will happen or
> > > not. Perhaps pure BSD header file will lead to pure BSD implementation.
> > > Perhaps?
> > >
> > > As for alternative dependency, it's possible if we make some major
> > changes
> > > to Weex. But convenience binary of each Weex release includes Webkit.so,
> > > how to solve that problem? Maybe publish two convenience binary, one
> > named
> > > Weex_WebKit.aar and the other named Weex_BSDKit.aar ? Not sounds like a
> > > good idea to me.
> > >
> > > Best Regards,
> > > YorkShen
> > >
> > > 申远
> > >
> > >
> > > Sheng Wu  于2019年6月14日周五 下午4:23写道：
> > >
> > >> Hi York
> > >>
> > >> I am not a C/C++ coder, so I could be wrong.
> > >>
> > >> But from I saw, Catalog X dependency required is not right. Like Hen
> > said,
> > >> alternative is an option.
> > >>
> > >> Such as
> > >> Today’s another incubating project, ShardingSphere.
> > >> When user wants to MySQL sharing, then they needs to accept MySQL Driver
> > >> license first(or already accepted).
> > >> But user could use ShardingSphere with PostgreSQL JDBC Driver.
> > >>
> > >>
> > >> Sheng Wu
> > >> Apache Skywalking, ShardingSphere, Zipkin
> > >>
> > >>
> > >>
> > >>> 在 2019年6月14日，下午4:15，Hen  写道：
> > >>>
> > >>> Assuming Weex requires Webkit and is unable to work with an
> > alternative,
> > >>> the issue here is that users of Weex would seem to have to permit
> > reverse
> > >>> engineering in their legal terms. Our position has been that that goes
> > >>> beyond the scope of the Apache 2.0 license and would be an unpleasant
> > >>> surprise for users.
> > >>>
> > >>> (seem to have to  =>  this is how we've discussed the license; an
> > actual
> > >>> court may decide something completely different)
> > >>>
> > >>> Looking at Weex's website's description, it does not seem to be that a
> > >> user
> > >>> of Weex will already have agreed to the terms of Webkit; thus I believe
> > >>> they would be unpleasantly surprised.
> > >>>
> > >>> Hen
> > >>>
> > >>> On Fri, Jun 14, 2019 at 12:49 AM 申远  wrote:
> > >>>
> >  Hi,
> > 
> >  I am a PPMC member of Apache Weex. After serious reviewing of our
> >  dependencies, I found there some of the source code we copied from
> > >> Webkit
> >  is actually under LGPL license(Category X) and our license format
> > tools
> >  changed the license header of these files to Apache v2 incorrectly.
> > I'd
> >  like to hear advice from incubator that whether our actions below
> > would
> > >> fix
> >  the Category X issue.
> > 
> >  First of all, License for Webkit is complicated, as it's said that
> > >> "WebKit
> >  is open source software with portions licensed under the LGPL and BSD
> >  licenses available here." [1].
> > 
> >  Now, Weex includes 1500 header files( .h files) from Webkit at
> > compiling
> >  stage and around 150 of the are under BSD License. At runtime, Weex
> > will
> >  dynamic links to the shared library of Webkit.
> > 
> >  After some major change, Weex could just include around 50 headers(.h
> >  files) at compiling stage and all of them are under BSD license. At
> >  runtime, Weex still needs to dynamic links to the shared library of
> > >> Webkit
> >  as before.
> > 
> >  As Webkit is under dual license, and it's almost impossible for us to
> >  figure out whether there is an function call chain like
> >  Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL.apiD. I'd
> > like
> > >> to
> >  know our proposed change is enough to fix the Category X dependency.
> > 
> >  [1] https://webkit.org/licensing-webkit/
> > 
> >  Best Regards,
> >  YorkShen
> > 
> >  申远
> > 
> > >>
> > >>
> > >> -
> > >> To unsubscribe, e-mail: 

Re: LGPL dependency

[Matt Sicker]

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

[Justin Mclean]

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

[Craig Russell]

The Webkit license page https://webkit.org/licensing-webkit/ says portions 
licensed under LGPL and BSD licenses.

Usually this means it's the user's choice which license to use.

We would choose the BSD License for the components that we use.

Can you find anywhere a statement that the Webkit.so is licensed only under 
LGPL?

Craig

> On Jun 14, 2019, at 1:40 AM, 申远  wrote:
> 
> As mentioned above, Webkit is under dual License(BSD and LPGL) and it's
> almost impossible for us to figure out which function is a pure BSD
> function. I don't know
> Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL will happen or
> not. Perhaps pure BSD header file will lead to pure BSD implementation.
> Perhaps?
> 
> As for alternative dependency, it's possible if we make some major changes
> to Weex. But convenience binary of each Weex release includes Webkit.so,
> how to solve that problem? Maybe publish two convenience binary, one named
> Weex_WebKit.aar and the other named Weex_BSDKit.aar ? Not sounds like a
> good idea to me.
> 
> Best Regards,
> YorkShen
> 
> 申远
> 
> 
> Sheng Wu  于2019年6月14日周五 下午4:23写道：
> 
>> Hi York
>> 
>> I am not a C/C++ coder, so I could be wrong.
>> 
>> But from I saw, Catalog X dependency required is not right. Like Hen said,
>> alternative is an option.
>> 
>> Such as
>> Today’s another incubating project, ShardingSphere.
>> When user wants to MySQL sharing, then they needs to accept MySQL Driver
>> license first(or already accepted).
>> But user could use ShardingSphere with PostgreSQL JDBC Driver.
>> 
>> 
>> Sheng Wu
>> Apache Skywalking, ShardingSphere, Zipkin
>> 
>> 
>> 
>>> 在 2019年6月14日，下午4:15，Hen  写道：
>>> 
>>> Assuming Weex requires Webkit and is unable to work with an alternative,
>>> the issue here is that users of Weex would seem to have to permit reverse
>>> engineering in their legal terms. Our position has been that that goes
>>> beyond the scope of the Apache 2.0 license and would be an unpleasant
>>> surprise for users.
>>> 
>>> (seem to have to  =>  this is how we've discussed the license; an actual
>>> court may decide something completely different)
>>> 
>>> Looking at Weex's website's description, it does not seem to be that a
>> user
>>> of Weex will already have agreed to the terms of Webkit; thus I believe
>>> they would be unpleasantly surprised.
>>> 
>>> Hen
>>> 
>>> On Fri, Jun 14, 2019 at 12:49 AM 申远  wrote:
>>> 
 Hi,
 
 I am a PPMC member of Apache Weex. After serious reviewing of our
 dependencies, I found there some of the source code we copied from
>> Webkit
 is actually under LGPL license(Category X) and our license format tools
 changed the license header of these files to Apache v2 incorrectly. I'd
 like to hear advice from incubator that whether our actions below would
>> fix
 the Category X issue.
 
 First of all, License for Webkit is complicated, as it's said that
>> "WebKit
 is open source software with portions licensed under the LGPL and BSD
 licenses available here." [1].
 
 Now, Weex includes 1500 header files( .h files) from Webkit at compiling
 stage and around 150 of the are under BSD License. At runtime, Weex will
 dynamic links to the shared library of Webkit.
 
 After some major change, Weex could just include around 50 headers(.h
 files) at compiling stage and all of them are under BSD license. At
 runtime, Weex still needs to dynamic links to the shared library of
>> Webkit
 as before.
 
 As Webkit is under dual license, and it's almost impossible for us to
 figure out whether there is an function call chain like
 Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL.apiD. I'd like
>> to
 know our proposed change is enough to fix the Category X dependency.
 
 [1] https://webkit.org/licensing-webkit/
 
 Best Regards,
 YorkShen
 
 申远
 
>> 
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
>> 

Craig L Russell
c...@apache.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: LGPL dependency

[申远]

Sorry for my late reply, I have open a JIRA issue[1] for this problem.

I'm really appreciated your help here, thank you all.

[1] https://issues.apache.org/jira/browse/LEGAL-464

Best Regards,
YorkShen

申远


申远  于2019年6月18日周二 下午8:08写道：

> Thanks for help.
>
> I will bring this to legal-jira this weeks later.
>
> Best Regards,
> YorkShen
>
> 申远
>
>
> Myrle Krantz  于2019年6月17日周一 下午8:07写道：
>
>> Thank you all,
>>
>> YorkShen, I think at this point the best thing to do is to open a "legal"
>> ticket at this Jira (https://issues.apache.org/jira/browse/LEGAL).  I
>> suspect that if you're only including the BSD-licensed headers, that Weex
>> will only be dependent on BSD-licensed code.  It's possible that the
>> "runtime" argument will work in this case too.
>>
>> But this discussion hasn't made me feel confident in either statement, and
>> there are other Apache projects for which this question may be relevant.
>> I'd like a final answer and the legal committee can provide that.
>>
>> Let me know if you need help formulating the ticket.
>>
>> Best Regards,
>> Myrle
>>
>> On Fri, Jun 14, 2019 at 7:13 PM Alex Harui 
>> wrote:
>>
>> > Some  things I don't think have been mentioned in this thread so far:
>> >
>> > 1) Even if you make Webkit optional by offering V8, I believe the ASF
>> > criteria for "optional" includes "less than half of your users will use
>> > that option" and so if Webkit offers better performance and most of the
>> > users select Webkit over V8, it won't really qualify Webkit as optional.
>> > 2) AIUI, the ASF does not care about the licensing of RUNTIMES (my
>> > emphasis) your project's code runs on.  Otherwise, no ASF project could
>> run
>> > on Windows or OSX.  Apache Flex runs on Adobe Flash/AIR runtimes.
>> > 3) I could not quickly find a direct quote for this, but I believe the
>> ASF
>> > does not care about the licensing of BUILD TOOLS (emphasis mine) used to
>> > manipulate the source in the source release as long as the license of
>> those
>> > tools does not constrain usage of that code (like some non-commercial
>> > restriction, or even a "no evil" restriction.
>> >
>> > AIUI, the whole purpose of these restrictions is to not place
>> restrictions
>> > on modifications to source or use of source when that source is
>> eventually
>> > executed (whether interpreted or compiled or other).
>> >
>> > So, if I've made that clear so far, the question I have for Weex is:
>> How
>> > is Webkit used in Weex?  Is it just a runtime and libraries for that
>> > runtime?  If so, then I believe it is ok to have a dependency on LGPL
>> > Webkit, but I would recommend that you find a way to not bundle Webkit
>> in
>> > the release artifacts.  Have it downloaded or make it a "prerequisite"
>> just
>> > like I think every ASF Java-based project says you must install a Java
>> JDK
>> > and don't bundle Java JDKs.
>> >
>> > Other questions to ask relative to whether Webkit is a runtime or build
>> > tool:
>> >
>> > A) Will anybody realistically want to modify the Webkit sources in order
>> > to use Weex?  If no, that's great, and another reason to not bundle
>> those
>> > header files with your sources.
>> > B) Will use of the WebKit header files and other binaries you depend on
>> > create a restriction on use?  If no, that's great as well, and I think
>> if
>> > the answer to A and B are both "no", the IPMC should consider Webkit to
>> be
>> > a runtime/build-tool dependency and let it go.
>> >
>> > HTH,
>> > -Alex
>> >
>> >
>> > On 6/14/19, 5:09 AM, "York Shen"  wrote:
>> >
>> > It depends on the definition of optional dependency. Weex targets
>> iOS,
>> > Android and Browser environment and Webkit header files and shared
>> library
>> > are only bundled for Android environment. As for other environments,
>> the OS
>> > or browser itself has exposed enough API for Weex.
>> >
>> > PS: I am pretty sure that the iOS system itself uses almost the same
>> > code of Webkit as Weex does to build its WKWebView. It’s really strange
>> > that’s ok for Weex iOS and not ok for Weex Android.
>> >
>> > > 在 2019年6月14日，19:17，Justin Mclean  写道：
>> > >
>> > > Hi,
>> > >
>> > >> Well, what if Weex copies some BSD header files in Webkit then
>> run
>> > on Webkit? IMHO, the Webkit is also an environment for Weex in this
>> case.
>> > >
>> > > You still didi not answer if this is an optional dependancy? But
>> > again either way I suggest you ask on legal discuss.
>> > >
>> > > Thanks,
>> > > Justin
>> > >
>> > >
>> > >
>> > >
>> -
>> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> > > For additional commands, e-mail:
>> general-h...@incubator.apache.org
>> > >
>> >
>> >
>> >
>>  -
>> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> > For additional 

Re: LGPL dependency

[申远]

Thanks for help.

I will bring this to legal-jira this weeks later.

Best Regards,
YorkShen

申远


Myrle Krantz  于2019年6月17日周一 下午8:07写道：

> Thank you all,
>
> YorkShen, I think at this point the best thing to do is to open a "legal"
> ticket at this Jira (https://issues.apache.org/jira/browse/LEGAL).  I
> suspect that if you're only including the BSD-licensed headers, that Weex
> will only be dependent on BSD-licensed code.  It's possible that the
> "runtime" argument will work in this case too.
>
> But this discussion hasn't made me feel confident in either statement, and
> there are other Apache projects for which this question may be relevant.
> I'd like a final answer and the legal committee can provide that.
>
> Let me know if you need help formulating the ticket.
>
> Best Regards,
> Myrle
>
> On Fri, Jun 14, 2019 at 7:13 PM Alex Harui 
> wrote:
>
> > Some  things I don't think have been mentioned in this thread so far:
> >
> > 1) Even if you make Webkit optional by offering V8, I believe the ASF
> > criteria for "optional" includes "less than half of your users will use
> > that option" and so if Webkit offers better performance and most of the
> > users select Webkit over V8, it won't really qualify Webkit as optional.
> > 2) AIUI, the ASF does not care about the licensing of RUNTIMES (my
> > emphasis) your project's code runs on.  Otherwise, no ASF project could
> run
> > on Windows or OSX.  Apache Flex runs on Adobe Flash/AIR runtimes.
> > 3) I could not quickly find a direct quote for this, but I believe the
> ASF
> > does not care about the licensing of BUILD TOOLS (emphasis mine) used to
> > manipulate the source in the source release as long as the license of
> those
> > tools does not constrain usage of that code (like some non-commercial
> > restriction, or even a "no evil" restriction.
> >
> > AIUI, the whole purpose of these restrictions is to not place
> restrictions
> > on modifications to source or use of source when that source is
> eventually
> > executed (whether interpreted or compiled or other).
> >
> > So, if I've made that clear so far, the question I have for Weex is:  How
> > is Webkit used in Weex?  Is it just a runtime and libraries for that
> > runtime?  If so, then I believe it is ok to have a dependency on LGPL
> > Webkit, but I would recommend that you find a way to not bundle Webkit in
> > the release artifacts.  Have it downloaded or make it a "prerequisite"
> just
> > like I think every ASF Java-based project says you must install a Java
> JDK
> > and don't bundle Java JDKs.
> >
> > Other questions to ask relative to whether Webkit is a runtime or build
> > tool:
> >
> > A) Will anybody realistically want to modify the Webkit sources in order
> > to use Weex?  If no, that's great, and another reason to not bundle those
> > header files with your sources.
> > B) Will use of the WebKit header files and other binaries you depend on
> > create a restriction on use?  If no, that's great as well, and I think if
> > the answer to A and B are both "no", the IPMC should consider Webkit to
> be
> > a runtime/build-tool dependency and let it go.
> >
> > HTH,
> > -Alex
> >
> >
> > On 6/14/19, 5:09 AM, "York Shen"  wrote:
> >
> > It depends on the definition of optional dependency. Weex targets
> iOS,
> > Android and Browser environment and Webkit header files and shared
> library
> > are only bundled for Android environment. As for other environments, the
> OS
> > or browser itself has exposed enough API for Weex.
> >
> > PS: I am pretty sure that the iOS system itself uses almost the same
> > code of Webkit as Weex does to build its WKWebView. It’s really strange
> > that’s ok for Weex iOS and not ok for Weex Android.
> >
> > > 在 2019年6月14日，19:17，Justin Mclean  写道：
> > >
> > > Hi,
> > >
> > >> Well, what if Weex copies some BSD header files in Webkit then run
> > on Webkit? IMHO, the Webkit is also an environment for Weex in this case.
> > >
> > > You still didi not answer if this is an optional dependancy? But
> > again either way I suggest you ask on legal discuss.
> > >
> > > Thanks,
> > > Justin
> > >
> > >
> > >
> > >
> -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>

Re: LGPL dependency

[Myrle Krantz]

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

[Alex Harui]

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

[Dave Fisher]

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

[Dave Fisher]

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

[York Shen]

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

[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

Re: LGPL dependency

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

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

[York Shen]

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

[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

[Myrle Krantz]

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

[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

[Justin Mclean]

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

[Sheng Wu]

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

[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
>
> 申远
>

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

[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

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!

[Luciano Resende]

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!

[Henry Saputra]

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!

[Gino Bustelo]

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

[Henri Yandell]

Brilliant :)

On Thursday, March 17, 2016, Chip Senkbeil <chip.senkb...@gmail.com> 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 <lbust...@gmail.com
> <javascript:;>> 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 <bay...@apache.org
> <javascript:;>> 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 <johndam...@apache.org
> <javascript:;>>
> 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 <johndam...@apache.org
> <javascript:;>>
> > >>> 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 <g...@bustelos.com
> <javascript:;>>
> > 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 inte

Re: Update on Apache Toree and LGPL dependency

[Chip Senkbeil]

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 <lbust...@gmail.com> 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 <bay...@apache.org> 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 <johndam...@apache.org>
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 <johndam...@apache.org>
> >>> 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 <g...@bustelos.com>
> 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

Re: Update on Apache Toree and LGPL dependency

[Jim Jagielski]

+1

> On Mar 6, 2016, at 6:58 PM, Gino Bustelo <lbust...@gmail.com> 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 <bay...@apache.org> 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 <johndam...@apache.org> 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 <johndam...@apache.org>
>>> 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 <g...@bustelos.com> 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

[Gino Bustelo]

@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 <bay...@apache.org> 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 <johndam...@apache.org> 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 <johndam...@apache.org>
>> 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 <g...@bustelos.com> 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

[Henri Yandell]

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 <johndam...@apache.org> 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 <johndam...@apache.org>
> 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 <g...@bustelos.com> 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

[John D. Ament]

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

[John D. Ament]

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

[Gino Bustelo]

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

[Gino Bustelo]

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

[Stian Soiland-Reyes]

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

[Gino Bustelo]

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