www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: License for using 3rd-party code (ECharts podling question)
Date Mon, 04 Feb 2019 19:29:03 GMT
Sorry wrong podling in the subject.

> On Feb 4, 2019, at 11:28 AM, Dave Fisher <dave2wave@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 <sushuang0322@gmail.com <mailto:sushuang0322@gmail.com>>
>> 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,
>> 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
) 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, 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

View raw message