incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Myrle Krantz <my...@apache.org>
Subject Re: LGPL dependency
Date Mon, 17 Jun 2019 12:07:37 GMT
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 <aharui@adobe.com.invalid> 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" <shenyuancs@gmail.com> 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 <justin@classsoftware.com>
写道:
>     >
>     > 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-unsubscribe@incubator.apache.org
>     > For additional commands, e-mail: general-help@incubator.apache.org
>     >
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>     For additional commands, e-mail: general-help@incubator.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message