Sorry wrong podling in the subject.
> On Feb 4, 2019, at 11:28 AM, Dave Fisher <dave2w...@comcast.net> 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 <sushuang0...@gmail.com
>> <mailto:sushuang0...@gmail.com>> 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
>
