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 <[email protected]> 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/ 
> <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
>  
> <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
>  
> <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
>  
> <https://github.com/d3/d3/blob/9cc9a875e636a1dcf36cc1e07bdf77e1ad6e2c74/src/arrays/nest.js>
>  ). So this file
> probably should be under the d3 license, but not an Apache License, isn't?
> If so, the Apache License header of this file is needed to be removed.
> 
> In the past years of the coding practice of echarts, most of the cases that 
> need to learn from third-party
> is follow the case like <1><2><3><4><6>.
> So if the solution I described above is reasonable/acceptable, that would be 
> good to be followed in future
> development. If not, we need to find some other practicable solution about 
> this and guide the development.
> 
> 
> 1. https://www.apache.org/legal/src-headers.html#3party 
> <https://www.apache.org/legal/src-headers.html#3party>
> 
> 
> Thanks,
> Su Shuang

Reply via email to