Re: License for using 3rd-party code (ECharts podling question)

[Dave Fisher]

Sorry wrong podling in the subject.

> On Feb 4, 2019, at 11:28 AM, Dave Fisher  wrote:
> 
> Hi -
> 
> I did a quick look at these files and want to try to state the situation 
> simply.
> 
> (A) <1><2><3><4><6> all represent code that was inspired by the study of D3 
> but are substantially different and never were a direct derivation. As such 
> ALv2 is appropriate while it is inspired by D3 with a BSD-3 license.
> 
> (B) <5> I need clarification. Is this more like the others in case (A) or was 
> it once a D3 copy that is from prior to 2013? If so then the file should 
> remain BSD-3 with a note that it is substantially modified?
> 
> IMO - the podling is doing a reasonable approach.
> 
> Legal peeps - what do you think?
> 
> Regards,
> Dave
> 
>> On Feb 1, 2019, at 11:03 AM, SHUANG SU > > wrote:
>> 
>> 
>> Hi,
>> 
>> Thanks a lot for the attention and checking.
>> 
>> > > To be more specific, here are some types of files:
>> > > 1. Some part of a file (maybe several lines, or a short function) is 
>> > > copied directly from a 3rd-party implementation, but others are 
>> > > implemented by ourselves.
>> > > 2. The code is implemented by us, but the general idea or algorithm is 
>> > > inspired by 3rd-party.
>> 
>> > ASF policy [1] states that you should not add the standard Apache License 
>> > header to the top of third-party source files, and only if major 
>> > modifications are done then the (P)PMC should decide what to do. IMO that 
>> > decision would need to be documented on the mailing list. INAL but from 
>> > what I’ve  seen previously option 2 is generally not enough change to 
>> > change the 3rd party license.
>> 
>> In my opinion, both the cases that a code snippet "copied from a 3rd-party" 
>> or "the idea/algorithm inspired by 3rd-party" 
>> need to follow the third-party license. In fact, in the current source code 
>> of Apache-echarts, there
>> is no case that "a code snippet need to change the origin third-party 
>> license".
>> 
>> But the key point we are confused and discussed here is:
>> "how to arrange the presence of the license statement in the source code 
>> files
>> when some code follows the Apache License and some follows the third-party 
>> license".
>> 
>> To find a practicable way to solve this issue and guide the future coding,
>> I think we need to go deep into these source files:
>> 
>> These source files of the release candidate of Apache-echarts 4.2.1-rc.1
>> ( https://dist.apache.org/repos/dist/dev/incubator/echarts/4.2.1-rc.1/ 
>>  )
>> are questioned about the embedded third-party license:
>> 
>> <1> src/util/number.js
>> <2> src/chart/treemap/treemapLayout.js
>> <3> src/chart/tree/layoutHelper.js
>> <4> src/chart/graph/forceHelper.js
>> <5> src/util/array/nest.js
>> <6> src/scale/Time.js
>> 
>> ASF policy [1] states that you should not add the standard Apache License 
>> header to the top of third-party source files.
>> But in the questioned source files listed above, file <1><2><3><4><6> are 
>> not from the third-party.
>> They are made up by the code of Apache-echarts itself, but including some 
>> "code snippet"
>> copied from or algorithm learned from the third-party library "d3", which is 
>> under BSD 3-Clause.
>> So these files have the Apache License header and embed d3 license next to 
>> the corresponding "code snippet".
>> And for standing out for the users, there is also a statement such as 
>> "the implementation references to d3 and follows d3 license ..." on the top 
>> of the file, next to the Apache License header.
>> 
>> So in my opinion <1><2><3><4><6> does not break the ASF policy [1], because 
>> they are not the third-party source file, 
>> but an Apache-licensed source file with third-party license embedded.
>> 
>> Let's take the file "src/chart/treemap/treemapLayout.js" as an example:
>> The code snippet "squarify" ( 
>> https://github.com/apache/incubator-echarts/blob/9234f0309137250a2561212e8ecd1639551119b1/src/chart/treemap/treemapLayout.js#L166
>>  
>> 
>>  ) is learned from d3 ( 
>> https://github.com/d3/d3/blob/28acd11a242245b8bd32cfcdaaa8d7d382c6272f/src/layout/treemap.js#L30
>>  
>> 
>>  ) on the skeleton of the algorithm.
>> But the entire file is the implementation of the echarts treemap, including 
>> not only the learned part but also lots of other logic 
>> related to each other and not appropriate to be separated.
>> So I think the file "src/chart/treemap/treemapLayout.js" should be under the 
>> Apache License header, and have d3 license embedded in some of the code.
>> 
>> And about the file <5>, the whole file is modified from the previous version 
>> of d3 (the version is about 3 years ago, 

Re: License for using 3rd-party code (Doris podling question)

[Dave Fisher]

Hi -

I did a quick look at these files and want to try to state the situation simply.

(A) <1><2><3><4><6> all represent code that was inspired by the study of D3 but 
are substantially different and never were a direct derivation. As such ALv2 is 
appropriate while it is inspired by D3 with a BSD-3 license.

(B) <5> I need clarification. Is this more like the others in case (A) or was 
it once a D3 copy that is from prior to 2013? If so then the file should remain 
BSD-3 with a note that it is substantially modified?

IMO - the podling is doing a reasonable approach.

Legal peeps - what do you think?

Regards,
Dave

> On Feb 1, 2019, at 11:03 AM, SHUANG SU  wrote:
> 
> 
> Hi,
> 
> Thanks a lot for the attention and checking.
> 
> > > To be more specific, here are some types of files:
> > > 1. Some part of a file (maybe several lines, or a short function) is 
> > > copied directly from a 3rd-party implementation, but others are 
> > > implemented by ourselves.
> > > 2. The code is implemented by us, but the general idea or algorithm is 
> > > inspired by 3rd-party.
> 
> > ASF policy [1] states that you should not add the standard Apache License 
> > header to the top of third-party source files, and only if major 
> > modifications are done then the (P)PMC should decide what to do. IMO that 
> > decision would need to be documented on the mailing list. INAL but from 
> > what I’ve  seen previously option 2 is generally not enough change to 
> > change the 3rd party license.
> 
> In my opinion, both the cases that a code snippet "copied from a 3rd-party" 
> or "the idea/algorithm inspired by 3rd-party" 
> need to follow the third-party license. In fact, in the current source code 
> of Apache-echarts, there
> is no case that "a code snippet need to change the origin third-party 
> license".
> 
> But the key point we are confused and discussed here is:
> "how to arrange the presence of the license statement in the source code files
> when some code follows the Apache License and some follows the third-party 
> license".
> 
> To find a practicable way to solve this issue and guide the future coding,
> I think we need to go deep into these source files:
> 
> These source files of the release candidate of Apache-echarts 4.2.1-rc.1
> ( https://dist.apache.org/repos/dist/dev/incubator/echarts/4.2.1-rc.1/ 
>  )
> are questioned about the embedded third-party license:
> 
> <1> src/util/number.js
> <2> src/chart/treemap/treemapLayout.js
> <3> src/chart/tree/layoutHelper.js
> <4> src/chart/graph/forceHelper.js
> <5> src/util/array/nest.js
> <6> src/scale/Time.js
> 
> ASF policy [1] states that you should not add the standard Apache License 
> header to the top of third-party source files.
> But in the questioned source files listed above, file <1><2><3><4><6> are not 
> from the third-party.
> They are made up by the code of Apache-echarts itself, but including some 
> "code snippet"
> copied from or algorithm learned from the third-party library "d3", which is 
> under BSD 3-Clause.
> So these files have the Apache License header and embed d3 license next to 
> the corresponding "code snippet".
> And for standing out for the users, there is also a statement such as 
> "the implementation references to d3 and follows d3 license ..." on the top 
> of the file, next to the Apache License header.
> 
> So in my opinion <1><2><3><4><6> does not break the ASF policy [1], because 
> they are not the third-party source file, 
> but an Apache-licensed source file with third-party license embedded.
> 
> Let's take the file "src/chart/treemap/treemapLayout.js" as an example:
> The code snippet "squarify" ( 
> https://github.com/apache/incubator-echarts/blob/9234f0309137250a2561212e8ecd1639551119b1/src/chart/treemap/treemapLayout.js#L166
>  
> 
>  ) is learned from d3 ( 
> https://github.com/d3/d3/blob/28acd11a242245b8bd32cfcdaaa8d7d382c6272f/src/layout/treemap.js#L30
>  
> 
>  ) on the skeleton of the algorithm.
> But the entire file is the implementation of the echarts treemap, including 
> not only the learned part but also lots of other logic 
> related to each other and not appropriate to be separated.
> So I think the file "src/chart/treemap/treemapLayout.js" should be under the 
> Apache License header, and have d3 license embedded in some of the code.
> 
> And about the file <5>, the whole file is modified from the previous version 
> of d3 (the version is about 3 years ago, 
> https://github.com/d3/d3/blob/9cc9a875e636a1dcf36cc1e07bdf77e1ad6e2c74/src/arrays/nest.js
>  
> 
>  ). So this file
> probably should be under the d3 license, 

[GitHub] knadt commented on issue #8018: echart yAxis and xAxis label cutout

[GitBox]

knadt commented on issue #8018: echart yAxis and xAxis label cutout
URL: 
https://github.com/apache/incubator-echarts/issues/8018#issuecomment-460345645
 
 
   Any update?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] klausb commented on issue #6202: Problems when updating chart through echartsInstance.setOption()

[GitBox]

klausb commented on issue #6202: Problems when updating chart through 
echartsInstance.setOption()
URL: 
https://github.com/apache/incubator-echarts/issues/6202#issuecomment-460327293
 
 
   @jonalxh, but this will kill the animation between the states. I use the 
same approach, but it would be great if the removal of a line from a multiline 
chart would not force me to rmove all and then to add n-1 again.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

[GitHub] jonalxh commented on issue #6202: Problems when updating chart through echartsInstance.setOption()

[GitBox]

jonalxh commented on issue #6202: Problems when updating chart through 
echartsInstance.setOption()
URL: 
https://github.com/apache/incubator-echarts/issues/6202#issuecomment-460322781
 
 
   I've solved it just clearing the chart variable before passing the options:
   ```
   var myChart = echarts.init(document.getElementById("bar-chart"));
   myChart.clear();
   myChart.setOption(option, true), $(function () { ... }
   ```
   
   It works nice.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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

Re: Invite you to be an ECharts committer

[Jaroslav Benc]

Hi Deqing Li,
thanks for your email and sorry for a longer reply, I'm not on a different
project so not sure if I can dedicate as much time as I used to but happy
to give you a hand with some bugs etc. How does the process work? Is there
a list of issues planned issues that I can look at?

Best Regards to you as well,
Cheers,
Jaro

On Wed, Jan 16, 2019 at 4:48 AM Deqing Li  wrote:

> Dear jarben,
>
> I am Deqing Li , is one of the PMC members
> of Apache incubator project-ECharts. Hoping that you still remember me,
> since we discussed a lot about Sankey diagram before. The purpose of my
> letter is to ask if you are interested in becoming our committer. Given
> that you have given us so many valuable suggestions before, It would be
> great if you can be our committer. Looking forward to your reply.
>
> Best Regards,
> Deqing Li
>
>
>
>
>
>

[GitHub] DenrizSusam opened a new pull request #9892: Typo in comment

[GitBox]

DenrizSusam opened a new pull request #9892: Typo in comment
URL: https://github.com/apache/incubator-echarts/pull/9892
 
 
   "Hence" instead of  "Hance".


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

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