You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@echarts.apache.org by Ovilia <ov...@gmail.com> on 2019/01/31 10:39:25 UTC
License for using 3rd-party code
Dear legal team,
In our incubating ECharts project, we have some code that is inspired by
3rd-party libraries but may not use their code directly. I'd like to ask
what should we do to the license headers of those files?
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.
We'd prefer that ASF license header is attached at the top of the files,
and annotations are commented at those positions that are inspired by
3rd-party libraries. But we wish to know if this is complying with Apache's
license. Please give some advice.
Zhang Wenli
http://zhangwenli.com
Re: License for using 3rd-party code (ECharts podling question)
Posted by Dave Fisher <da...@comcast.net>.
Sorry wrong podling in the subject.
> On Feb 4, 2019, at 11:28 AM, Dave Fisher <da...@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 <ma...@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
>
Re: License for using 3rd-party code (ECharts podling question)
Posted by Dave Fisher <da...@comcast.net>.
Sorry wrong podling in the subject.
> On Feb 4, 2019, at 11:28 AM, Dave Fisher <da...@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 <ma...@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
>
Re: License for using 3rd-party code (Doris podling question)
Posted by Dave Fisher <da...@comcast.net>.
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 <su...@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
Re: License for using 3rd-party code (Doris podling question)
Posted by Dave Fisher <da...@comcast.net>.
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 <su...@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
Re: License for using 3rd-party code
Posted by SHUANG SU <su...@gmail.com>.
Hi Justin & Hen,
I have made some changes about the third-party license, listed below:
<1> /src/util/number.js
*https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/src/util/number.js
<https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/src/util/number.js>*
<2> /src/chart/treemap/treemapLayout.js
*https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/src/chart/treemap/treemapLayout.js
<https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/src/chart/treemap/treemapLayout.js>*
<3> /src/chart/tree/layoutHelper.js
*https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/src/chart/tree/layoutHelper.js
<https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/src/chart/tree/layoutHelper.js>*
<4> /src/chart/graph/forceHelper.js
*https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/src/chart/graph/forceHelper.js
<https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/src/chart/graph/forceHelper.js>*
<5> /src/util/array/nest.js
Removed because it is not needed essentially.
<6> /src/scale/Time.js
*https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/src/scale/Time.js
<https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/src/scale/Time.js>*
<7> LICENSE
*https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/LICENSE
<https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/LICENSE>*
Could you please check them again whether there is any inappropriate
statement about the third-party license or copyright?
If all OK, I will release a new candidate and initiate a new vote for it.
Thanks,
------------------------------
Su Shuang (100pah)
------------------------------
On Sat, 16 Feb 2019 at 17:00, Hen <ba...@apache.org> wrote:
> On Fri, Feb 15, 2019 at 3:17 AM SHUANG SU <su...@gmail.com> wrote:
>
> >
> >
> > Hi Hen,
> >
> > Thank you so much for the detailed checking.
> >
> > There is one more question about this file:
> >
> > > > <1> src/util/number.js
> > > >
> > > This file says this:
> > > * @see <
> > https://github.com/mbostock/d3/blob/master/src/arrays/quantile.js>
> > > * @see <http://en.wikipedia.org/wiki/Quantile>
> > > Assuming no code was copied, this seems fine. If code was copied from
> > > either, then there is licensing to include (be that BSD for d3 or
> > CC-BY-SA
> > > for Quantile, the latter being a problem for us licensing wise).
> >
> > The method "quantile" in this file is only copied from the code of "d3"
> > [1], which is under BSD.
> > But the original code in "d3" [1] seems to use a formula on Wikipedia
> [2].
> > So is it OK to use this "d3" code in "echarts" and only embed the BSD
> > license of "d3" in the file "src/util/number.js" ?
> >
> >
> > [1].
> >
> https://github.com/d3/d3/blob/9cc9a875e636a1dcf36cc1e07bdf77e1ad6e2c74/src/arrays/quantile.js
> > [2]. https://en.wikipedia.org/wiki/Quantile . Search "R-7" in this page,
> > get the formula.
> >
> >
> Yes that's okay, treat that as you do other BSD licensed code copied from
> d3.
>
> The concept 'copied' from Wikipedia is the idea that a piece of mathematics
> represents; the formula itself doesn't have copyrightable expression and
> there's nothing else that appears to be being copied over from Wikipedia.
>
> Hen
>
Re: License for using 3rd-party code
Posted by SHUANG SU <su...@gmail.com>.
Hi Justin & Hen,
I have made some changes about the third-party license, listed below:
<1> /src/util/number.js
*https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/src/util/number.js
<https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/src/util/number.js>*
<2> /src/chart/treemap/treemapLayout.js
*https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/src/chart/treemap/treemapLayout.js
<https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/src/chart/treemap/treemapLayout.js>*
<3> /src/chart/tree/layoutHelper.js
*https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/src/chart/tree/layoutHelper.js
<https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/src/chart/tree/layoutHelper.js>*
<4> /src/chart/graph/forceHelper.js
*https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/src/chart/graph/forceHelper.js
<https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/src/chart/graph/forceHelper.js>*
<5> /src/util/array/nest.js
Removed because it is not needed essentially.
<6> /src/scale/Time.js
*https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/src/scale/Time.js
<https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/src/scale/Time.js>*
<7> LICENSE
*https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/LICENSE
<https://github.com/apache/incubator-echarts/blob/14cbb8008cbb8d3f058caaca6032209ecb000a1b/LICENSE>*
Could you please check them again whether there is any inappropriate
statement about the third-party license or copyright?
If all OK, I will release a new candidate and initiate a new vote for it.
Thanks,
------------------------------
Su Shuang (100pah)
------------------------------
On Sat, 16 Feb 2019 at 17:00, Hen <ba...@apache.org> wrote:
> On Fri, Feb 15, 2019 at 3:17 AM SHUANG SU <su...@gmail.com> wrote:
>
> >
> >
> > Hi Hen,
> >
> > Thank you so much for the detailed checking.
> >
> > There is one more question about this file:
> >
> > > > <1> src/util/number.js
> > > >
> > > This file says this:
> > > * @see <
> > https://github.com/mbostock/d3/blob/master/src/arrays/quantile.js>
> > > * @see <http://en.wikipedia.org/wiki/Quantile>
> > > Assuming no code was copied, this seems fine. If code was copied from
> > > either, then there is licensing to include (be that BSD for d3 or
> > CC-BY-SA
> > > for Quantile, the latter being a problem for us licensing wise).
> >
> > The method "quantile" in this file is only copied from the code of "d3"
> > [1], which is under BSD.
> > But the original code in "d3" [1] seems to use a formula on Wikipedia
> [2].
> > So is it OK to use this "d3" code in "echarts" and only embed the BSD
> > license of "d3" in the file "src/util/number.js" ?
> >
> >
> > [1].
> >
> https://github.com/d3/d3/blob/9cc9a875e636a1dcf36cc1e07bdf77e1ad6e2c74/src/arrays/quantile.js
> > [2]. https://en.wikipedia.org/wiki/Quantile . Search "R-7" in this page,
> > get the formula.
> >
> >
> Yes that's okay, treat that as you do other BSD licensed code copied from
> d3.
>
> The concept 'copied' from Wikipedia is the idea that a piece of mathematics
> represents; the formula itself doesn't have copyrightable expression and
> there's nothing else that appears to be being copied over from Wikipedia.
>
> Hen
>
Re: License for using 3rd-party code
Posted by Hen <ba...@apache.org>.
On Fri, Feb 15, 2019 at 3:17 AM SHUANG SU <su...@gmail.com> wrote:
>
>
> Hi Hen,
>
> Thank you so much for the detailed checking.
>
> There is one more question about this file:
>
> > > <1> src/util/number.js
> > >
> > This file says this:
> > * @see <
> https://github.com/mbostock/d3/blob/master/src/arrays/quantile.js>
> > * @see <http://en.wikipedia.org/wiki/Quantile>
> > Assuming no code was copied, this seems fine. If code was copied from
> > either, then there is licensing to include (be that BSD for d3 or
> CC-BY-SA
> > for Quantile, the latter being a problem for us licensing wise).
>
> The method "quantile" in this file is only copied from the code of "d3"
> [1], which is under BSD.
> But the original code in "d3" [1] seems to use a formula on Wikipedia [2].
> So is it OK to use this "d3" code in "echarts" and only embed the BSD
> license of "d3" in the file "src/util/number.js" ?
>
>
> [1].
> https://github.com/d3/d3/blob/9cc9a875e636a1dcf36cc1e07bdf77e1ad6e2c74/src/arrays/quantile.js
> [2]. https://en.wikipedia.org/wiki/Quantile . Search "R-7" in this page,
> get the formula.
>
>
Yes that's okay, treat that as you do other BSD licensed code copied from
d3.
The concept 'copied' from Wikipedia is the idea that a piece of mathematics
represents; the formula itself doesn't have copyrightable expression and
there's nothing else that appears to be being copied over from Wikipedia.
Hen
Re: License for using 3rd-party code
Posted by Hen <ba...@apache.org>.
On Fri, Feb 15, 2019 at 3:17 AM SHUANG SU <su...@gmail.com> wrote:
>
>
> Hi Hen,
>
> Thank you so much for the detailed checking.
>
> There is one more question about this file:
>
> > > <1> src/util/number.js
> > >
> > This file says this:
> > * @see <
> https://github.com/mbostock/d3/blob/master/src/arrays/quantile.js>
> > * @see <http://en.wikipedia.org/wiki/Quantile>
> > Assuming no code was copied, this seems fine. If code was copied from
> > either, then there is licensing to include (be that BSD for d3 or
> CC-BY-SA
> > for Quantile, the latter being a problem for us licensing wise).
>
> The method "quantile" in this file is only copied from the code of "d3"
> [1], which is under BSD.
> But the original code in "d3" [1] seems to use a formula on Wikipedia [2].
> So is it OK to use this "d3" code in "echarts" and only embed the BSD
> license of "d3" in the file "src/util/number.js" ?
>
>
> [1].
> https://github.com/d3/d3/blob/9cc9a875e636a1dcf36cc1e07bdf77e1ad6e2c74/src/arrays/quantile.js
> [2]. https://en.wikipedia.org/wiki/Quantile . Search "R-7" in this page,
> get the formula.
>
>
Yes that's okay, treat that as you do other BSD licensed code copied from
d3.
The concept 'copied' from Wikipedia is the idea that a piece of mathematics
represents; the formula itself doesn't have copyrightable expression and
there's nothing else that appears to be being copied over from Wikipedia.
Hen
Re: License for using 3rd-party code
Posted by SHUANG SU <su...@gmail.com>.
Hi Hen,
Thank you so much for the detailed checking.
There is one more question about this file:
> > <1> src/util/number.js
> >
> This file says this:
> * @see <https://github.com/mbostock/d3/blob/master/src/arrays/quantile.js
>
> * @see <http://en.wikipedia.org/wiki/Quantile>
> Assuming no code was copied, this seems fine. If code was copied from
> either, then there is licensing to include (be that BSD for d3 or CC-BY-SA
> for Quantile, the latter being a problem for us licensing wise).
The method "quantile" in this file is only copied from the code of "d3"
[1], which is under BSD.
But the original code in "d3" [1] seems to use a formula on Wikipedia [2].
So is it OK to use this "d3" code in "echarts" and only embed the BSD
license of "d3" in the file "src/util/number.js" ?
[1].
https://github.com/d3/d3/blob/9cc9a875e636a1dcf36cc1e07bdf77e1ad6e2c74/src/arrays/quantile.js
[2]. https://en.wikipedia.org/wiki/Quantile . Search "R-7" in this page,
get the formula.
Thanks,
------------------------------
Su Shuang (100pah)
------------------------------
On Mon, 11 Feb 2019 at 04:49, Hen <ba...@apache.org> wrote:
> On Fri, Feb 1, 2019 at 11:04 AM SHUANG SU <su...@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.
> >
> >
> "inspired by" and "learned from" are both, iiuc, vague concepts in
> copyright. There's no right given to learn from a piece of code or to be
> inspired by a piece of code. So the 'need to follow license' statement
> doesn't compile cleanly.
>
> What's the right thing to do for the public good here? I'll go with:
>
> * Be transparent when implementing an existing idea/algorithm.
> * Reference where that idea/algorithm came from.
> * Use standard language when doing so (we need to define standard
> language).
> * If any copyrightable expression is copied from the existing
> idea/algorithm, compare its licensing to our licensing policies and include
> licensing accordingly.
>
> 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
> >
>
> This file says this:
>
> * @see <https://github.com/mbostock/d3/blob/master/src/arrays/quantile.js
> >
> * @see <http://en.wikipedia.org/wiki/Quantile>
>
> Assuming no code was copied, this seems fine. If code was copied from
> either, then there is licensing to include (be that BSD for d3 or CC-BY-SA
> for Quantile, the latter being a problem for us licensing wise).
>
>
> > <2> src/chart/treemap/treemapLayout.js
> >
>
> This file says this:
>
> /*
> * The treemap layout implementation references to the treemap
> * layout of d3.js (d3/src/layout/treemap.js in v3). The use of
> * the source code of this file is also subject to the terms
> * and consitions of its license (BSD-3Clause, see
> * <echarts/src/licenses/LICENSE-d3>).
> */
>
> and later:
>
> * Layout treemap with squarify algorithm.
> * @see
>
> https://graphics.ethz.ch/teaching/scivis_common/Literature/squarifiedTreeMaps.pdf
> * The implementation references to the treemap layout of d3.js.
> * See the license statement at the head of this file.
>
> The 'references to' is confusing, I don't know what that is supposed to
> mean has happened. Assuming code has been copied from d3 into echarts here,
> which is not what 'references to' means, the rest of this would look good
> to me.
>
>
> > <3> src/chart/tree/layoutHelper.js
> >
>
> This file says this:
>
> /*
> * The tree layout implementation references to d3.js
> * (https://github.com/d3/d3-hierarchy). The use of the source
> * code of this file is also subject to the terms and consitions
> * of its license (BSD-3Clause, see <echarts/src/licenses/LICENSE-d3>).
> */
>
> /**
> * @file The layout algorithm of node-link tree diagrams. Here we using
> Reingold-Tilford algorithm to drawing
> * the tree.
> * @see https://github.com/d3/d3-hierarchy
> */
>
> My comments are the same as the previous item.
>
>
> > <4> src/chart/graph/forceHelper.js
> >
>
> Same 'references to' language. Later on it also says '// From d3' followed
> by a block of commented out code. It's not clear if that's meant to mean
> code has been copied.
>
>
> > <5> src/util/array/nest.js
> >
>
> Note that this was src/util.nest.js. Same 'references to' issue.
>
>
> > <6> src/scale/Time.js
> >
>
> Same 'references to' issue. Also says:
>
> // Steps from d3, see the license statement at the top of this file.
>
> which seems fine.
>
>
> > <snip by bayard@>
> >
> > 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.
> >
>
> If it's originally a 3rd party file, then I'd encourage doing:
>
> <Original license>
>
> <Modifications by Apache eCharts provided under Apache License 2.0>
>
> Hen
>
Re: License for using 3rd-party code
Posted by SHUANG SU <su...@gmail.com>.
Hi Hen,
Thank you so much for your detailed check!
There is one more question about this file:
>
>
The method "quantile" is copied from ij
------------------------------
Su Shuang (100pah)
------------------------------
On Mon, 11 Feb 2019 at 04:49, Hen <ba...@apache.org> wrote:
> On Fri, Feb 1, 2019 at 11:04 AM SHUANG SU <su...@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.
> >
> >
> "inspired by" and "learned from" are both, iiuc, vague concepts in
> copyright. There's no right given to learn from a piece of code or to be
> inspired by a piece of code. So the 'need to follow license' statement
> doesn't compile cleanly.
>
> What's the right thing to do for the public good here? I'll go with:
>
> * Be transparent when implementing an existing idea/algorithm.
> * Reference where that idea/algorithm came from.
> * Use standard language when doing so (we need to define standard
> language).
> * If any copyrightable expression is copied from the existing
> idea/algorithm, compare its licensing to our licensing policies and include
> licensing accordingly.
>
> 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
> >
>
> This file says this:
>
> * @see <https://github.com/mbostock/d3/blob/master/src/arrays/quantile.js
> >
> * @see <http://en.wikipedia.org/wiki/Quantile>
>
> Assuming no code was copied, this seems fine. If code was copied from
> either, then there is licensing to include (be that BSD for d3 or CC-BY-SA
> for Quantile, the latter being a problem for us licensing wise).
>
>
> > <2> src/chart/treemap/treemapLayout.js
> >
>
> This file says this:
>
> /*
> * The treemap layout implementation references to the treemap
> * layout of d3.js (d3/src/layout/treemap.js in v3). The use of
> * the source code of this file is also subject to the terms
> * and consitions of its license (BSD-3Clause, see
> * <echarts/src/licenses/LICENSE-d3>).
> */
>
> and later:
>
> * Layout treemap with squarify algorithm.
> * @see
>
> https://graphics.ethz.ch/teaching/scivis_common/Literature/squarifiedTreeMaps.pdf
> * The implementation references to the treemap layout of d3.js.
> * See the license statement at the head of this file.
>
> The 'references to' is confusing, I don't know what that is supposed to
> mean has happened. Assuming code has been copied from d3 into echarts here,
> which is not what 'references to' means, the rest of this would look good
> to me.
>
>
> > <3> src/chart/tree/layoutHelper.js
> >
>
> This file says this:
>
> /*
> * The tree layout implementation references to d3.js
> * (https://github.com/d3/d3-hierarchy). The use of the source
> * code of this file is also subject to the terms and consitions
> * of its license (BSD-3Clause, see <echarts/src/licenses/LICENSE-d3>).
> */
>
> /**
> * @file The layout algorithm of node-link tree diagrams. Here we using
> Reingold-Tilford algorithm to drawing
> * the tree.
> * @see https://github.com/d3/d3-hierarchy
> */
>
> My comments are the same as the previous item.
>
>
> > <4> src/chart/graph/forceHelper.js
> >
>
> Same 'references to' language. Later on it also says '// From d3' followed
> by a block of commented out code. It's not clear if that's meant to mean
> code has been copied.
>
>
> > <5> src/util/array/nest.js
> >
>
> Note that this was src/util.nest.js. Same 'references to' issue.
>
>
> > <6> src/scale/Time.js
> >
>
> Same 'references to' issue. Also says:
>
> // Steps from d3, see the license statement at the top of this file.
>
> which seems fine.
>
>
> > <snip by bayard@>
> >
> > 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.
> >
>
> If it's originally a 3rd party file, then I'd encourage doing:
>
> <Original license>
>
> <Modifications by Apache eCharts provided under Apache License 2.0>
>
> Hen
>
Re: License for using 3rd-party code
Posted by SHUANG SU <su...@gmail.com>.
Hi Hen,
Thank you so much for the detailed checking.
There is one more question about this file:
> > <1> src/util/number.js
> >
> This file says this:
> * @see <https://github.com/mbostock/d3/blob/master/src/arrays/quantile.js
>
> * @see <http://en.wikipedia.org/wiki/Quantile>
> Assuming no code was copied, this seems fine. If code was copied from
> either, then there is licensing to include (be that BSD for d3 or CC-BY-SA
> for Quantile, the latter being a problem for us licensing wise).
The method "quantile" in this file is only copied from the code of "d3"
[1], which is under BSD.
But the original code in "d3" [1] seems to use a formula on Wikipedia [2].
So is it OK to use this "d3" code in "echarts" and only embed the BSD
license of "d3" in the file "src/util/number.js" ?
[1].
https://github.com/d3/d3/blob/9cc9a875e636a1dcf36cc1e07bdf77e1ad6e2c74/src/arrays/quantile.js
[2]. https://en.wikipedia.org/wiki/Quantile . Search "R-7" in this page,
get the formula.
Thanks,
------------------------------
Su Shuang (100pah)
------------------------------
On Mon, 11 Feb 2019 at 04:49, Hen <ba...@apache.org> wrote:
> On Fri, Feb 1, 2019 at 11:04 AM SHUANG SU <su...@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.
> >
> >
> "inspired by" and "learned from" are both, iiuc, vague concepts in
> copyright. There's no right given to learn from a piece of code or to be
> inspired by a piece of code. So the 'need to follow license' statement
> doesn't compile cleanly.
>
> What's the right thing to do for the public good here? I'll go with:
>
> * Be transparent when implementing an existing idea/algorithm.
> * Reference where that idea/algorithm came from.
> * Use standard language when doing so (we need to define standard
> language).
> * If any copyrightable expression is copied from the existing
> idea/algorithm, compare its licensing to our licensing policies and include
> licensing accordingly.
>
> 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
> >
>
> This file says this:
>
> * @see <https://github.com/mbostock/d3/blob/master/src/arrays/quantile.js
> >
> * @see <http://en.wikipedia.org/wiki/Quantile>
>
> Assuming no code was copied, this seems fine. If code was copied from
> either, then there is licensing to include (be that BSD for d3 or CC-BY-SA
> for Quantile, the latter being a problem for us licensing wise).
>
>
> > <2> src/chart/treemap/treemapLayout.js
> >
>
> This file says this:
>
> /*
> * The treemap layout implementation references to the treemap
> * layout of d3.js (d3/src/layout/treemap.js in v3). The use of
> * the source code of this file is also subject to the terms
> * and consitions of its license (BSD-3Clause, see
> * <echarts/src/licenses/LICENSE-d3>).
> */
>
> and later:
>
> * Layout treemap with squarify algorithm.
> * @see
>
> https://graphics.ethz.ch/teaching/scivis_common/Literature/squarifiedTreeMaps.pdf
> * The implementation references to the treemap layout of d3.js.
> * See the license statement at the head of this file.
>
> The 'references to' is confusing, I don't know what that is supposed to
> mean has happened. Assuming code has been copied from d3 into echarts here,
> which is not what 'references to' means, the rest of this would look good
> to me.
>
>
> > <3> src/chart/tree/layoutHelper.js
> >
>
> This file says this:
>
> /*
> * The tree layout implementation references to d3.js
> * (https://github.com/d3/d3-hierarchy). The use of the source
> * code of this file is also subject to the terms and consitions
> * of its license (BSD-3Clause, see <echarts/src/licenses/LICENSE-d3>).
> */
>
> /**
> * @file The layout algorithm of node-link tree diagrams. Here we using
> Reingold-Tilford algorithm to drawing
> * the tree.
> * @see https://github.com/d3/d3-hierarchy
> */
>
> My comments are the same as the previous item.
>
>
> > <4> src/chart/graph/forceHelper.js
> >
>
> Same 'references to' language. Later on it also says '// From d3' followed
> by a block of commented out code. It's not clear if that's meant to mean
> code has been copied.
>
>
> > <5> src/util/array/nest.js
> >
>
> Note that this was src/util.nest.js. Same 'references to' issue.
>
>
> > <6> src/scale/Time.js
> >
>
> Same 'references to' issue. Also says:
>
> // Steps from d3, see the license statement at the top of this file.
>
> which seems fine.
>
>
> > <snip by bayard@>
> >
> > 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.
> >
>
> If it's originally a 3rd party file, then I'd encourage doing:
>
> <Original license>
>
> <Modifications by Apache eCharts provided under Apache License 2.0>
>
> Hen
>
Re: License for using 3rd-party code
Posted by SHUANG SU <su...@gmail.com>.
Hi Hen,
Thank you so much for your detailed check!
There is one more question about this file:
>
>
The method "quantile" is copied from ij
------------------------------
Su Shuang (100pah)
------------------------------
On Mon, 11 Feb 2019 at 04:49, Hen <ba...@apache.org> wrote:
> On Fri, Feb 1, 2019 at 11:04 AM SHUANG SU <su...@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.
> >
> >
> "inspired by" and "learned from" are both, iiuc, vague concepts in
> copyright. There's no right given to learn from a piece of code or to be
> inspired by a piece of code. So the 'need to follow license' statement
> doesn't compile cleanly.
>
> What's the right thing to do for the public good here? I'll go with:
>
> * Be transparent when implementing an existing idea/algorithm.
> * Reference where that idea/algorithm came from.
> * Use standard language when doing so (we need to define standard
> language).
> * If any copyrightable expression is copied from the existing
> idea/algorithm, compare its licensing to our licensing policies and include
> licensing accordingly.
>
> 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
> >
>
> This file says this:
>
> * @see <https://github.com/mbostock/d3/blob/master/src/arrays/quantile.js
> >
> * @see <http://en.wikipedia.org/wiki/Quantile>
>
> Assuming no code was copied, this seems fine. If code was copied from
> either, then there is licensing to include (be that BSD for d3 or CC-BY-SA
> for Quantile, the latter being a problem for us licensing wise).
>
>
> > <2> src/chart/treemap/treemapLayout.js
> >
>
> This file says this:
>
> /*
> * The treemap layout implementation references to the treemap
> * layout of d3.js (d3/src/layout/treemap.js in v3). The use of
> * the source code of this file is also subject to the terms
> * and consitions of its license (BSD-3Clause, see
> * <echarts/src/licenses/LICENSE-d3>).
> */
>
> and later:
>
> * Layout treemap with squarify algorithm.
> * @see
>
> https://graphics.ethz.ch/teaching/scivis_common/Literature/squarifiedTreeMaps.pdf
> * The implementation references to the treemap layout of d3.js.
> * See the license statement at the head of this file.
>
> The 'references to' is confusing, I don't know what that is supposed to
> mean has happened. Assuming code has been copied from d3 into echarts here,
> which is not what 'references to' means, the rest of this would look good
> to me.
>
>
> > <3> src/chart/tree/layoutHelper.js
> >
>
> This file says this:
>
> /*
> * The tree layout implementation references to d3.js
> * (https://github.com/d3/d3-hierarchy). The use of the source
> * code of this file is also subject to the terms and consitions
> * of its license (BSD-3Clause, see <echarts/src/licenses/LICENSE-d3>).
> */
>
> /**
> * @file The layout algorithm of node-link tree diagrams. Here we using
> Reingold-Tilford algorithm to drawing
> * the tree.
> * @see https://github.com/d3/d3-hierarchy
> */
>
> My comments are the same as the previous item.
>
>
> > <4> src/chart/graph/forceHelper.js
> >
>
> Same 'references to' language. Later on it also says '// From d3' followed
> by a block of commented out code. It's not clear if that's meant to mean
> code has been copied.
>
>
> > <5> src/util/array/nest.js
> >
>
> Note that this was src/util.nest.js. Same 'references to' issue.
>
>
> > <6> src/scale/Time.js
> >
>
> Same 'references to' issue. Also says:
>
> // Steps from d3, see the license statement at the top of this file.
>
> which seems fine.
>
>
> > <snip by bayard@>
> >
> > 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.
> >
>
> If it's originally a 3rd party file, then I'd encourage doing:
>
> <Original license>
>
> <Modifications by Apache eCharts provided under Apache License 2.0>
>
> Hen
>
Re: License for using 3rd-party code
Posted by Hen <ba...@apache.org>.
On Fri, Feb 1, 2019 at 11:04 AM SHUANG SU <su...@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.
>
>
"inspired by" and "learned from" are both, iiuc, vague concepts in
copyright. There's no right given to learn from a piece of code or to be
inspired by a piece of code. So the 'need to follow license' statement
doesn't compile cleanly.
What's the right thing to do for the public good here? I'll go with:
* Be transparent when implementing an existing idea/algorithm.
* Reference where that idea/algorithm came from.
* Use standard language when doing so (we need to define standard language).
* If any copyrightable expression is copied from the existing
idea/algorithm, compare its licensing to our licensing policies and include
licensing accordingly.
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
>
This file says this:
* @see <https://github.com/mbostock/d3/blob/master/src/arrays/quantile.js>
* @see <http://en.wikipedia.org/wiki/Quantile>
Assuming no code was copied, this seems fine. If code was copied from
either, then there is licensing to include (be that BSD for d3 or CC-BY-SA
for Quantile, the latter being a problem for us licensing wise).
> <2> src/chart/treemap/treemapLayout.js
>
This file says this:
/*
* The treemap layout implementation references to the treemap
* layout of d3.js (d3/src/layout/treemap.js in v3). The use of
* the source code of this file is also subject to the terms
* and consitions of its license (BSD-3Clause, see
* <echarts/src/licenses/LICENSE-d3>).
*/
and later:
* Layout treemap with squarify algorithm.
* @see
https://graphics.ethz.ch/teaching/scivis_common/Literature/squarifiedTreeMaps.pdf
* The implementation references to the treemap layout of d3.js.
* See the license statement at the head of this file.
The 'references to' is confusing, I don't know what that is supposed to
mean has happened. Assuming code has been copied from d3 into echarts here,
which is not what 'references to' means, the rest of this would look good
to me.
> <3> src/chart/tree/layoutHelper.js
>
This file says this:
/*
* The tree layout implementation references to d3.js
* (https://github.com/d3/d3-hierarchy). The use of the source
* code of this file is also subject to the terms and consitions
* of its license (BSD-3Clause, see <echarts/src/licenses/LICENSE-d3>).
*/
/**
* @file The layout algorithm of node-link tree diagrams. Here we using
Reingold-Tilford algorithm to drawing
* the tree.
* @see https://github.com/d3/d3-hierarchy
*/
My comments are the same as the previous item.
> <4> src/chart/graph/forceHelper.js
>
Same 'references to' language. Later on it also says '// From d3' followed
by a block of commented out code. It's not clear if that's meant to mean
code has been copied.
> <5> src/util/array/nest.js
>
Note that this was src/util.nest.js. Same 'references to' issue.
> <6> src/scale/Time.js
>
Same 'references to' issue. Also says:
// Steps from d3, see the license statement at the top of this file.
which seems fine.
> <snip by bayard@>
>
> 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.
>
If it's originally a 3rd party file, then I'd encourage doing:
<Original license>
<Modifications by Apache eCharts provided under Apache License 2.0>
Hen
Re: License for using 3rd-party code
Posted by Hen <ba...@apache.org>.
On Fri, Feb 1, 2019 at 11:04 AM SHUANG SU <su...@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.
>
>
"inspired by" and "learned from" are both, iiuc, vague concepts in
copyright. There's no right given to learn from a piece of code or to be
inspired by a piece of code. So the 'need to follow license' statement
doesn't compile cleanly.
What's the right thing to do for the public good here? I'll go with:
* Be transparent when implementing an existing idea/algorithm.
* Reference where that idea/algorithm came from.
* Use standard language when doing so (we need to define standard language).
* If any copyrightable expression is copied from the existing
idea/algorithm, compare its licensing to our licensing policies and include
licensing accordingly.
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
>
This file says this:
* @see <https://github.com/mbostock/d3/blob/master/src/arrays/quantile.js>
* @see <http://en.wikipedia.org/wiki/Quantile>
Assuming no code was copied, this seems fine. If code was copied from
either, then there is licensing to include (be that BSD for d3 or CC-BY-SA
for Quantile, the latter being a problem for us licensing wise).
> <2> src/chart/treemap/treemapLayout.js
>
This file says this:
/*
* The treemap layout implementation references to the treemap
* layout of d3.js (d3/src/layout/treemap.js in v3). The use of
* the source code of this file is also subject to the terms
* and consitions of its license (BSD-3Clause, see
* <echarts/src/licenses/LICENSE-d3>).
*/
and later:
* Layout treemap with squarify algorithm.
* @see
https://graphics.ethz.ch/teaching/scivis_common/Literature/squarifiedTreeMaps.pdf
* The implementation references to the treemap layout of d3.js.
* See the license statement at the head of this file.
The 'references to' is confusing, I don't know what that is supposed to
mean has happened. Assuming code has been copied from d3 into echarts here,
which is not what 'references to' means, the rest of this would look good
to me.
> <3> src/chart/tree/layoutHelper.js
>
This file says this:
/*
* The tree layout implementation references to d3.js
* (https://github.com/d3/d3-hierarchy). The use of the source
* code of this file is also subject to the terms and consitions
* of its license (BSD-3Clause, see <echarts/src/licenses/LICENSE-d3>).
*/
/**
* @file The layout algorithm of node-link tree diagrams. Here we using
Reingold-Tilford algorithm to drawing
* the tree.
* @see https://github.com/d3/d3-hierarchy
*/
My comments are the same as the previous item.
> <4> src/chart/graph/forceHelper.js
>
Same 'references to' language. Later on it also says '// From d3' followed
by a block of commented out code. It's not clear if that's meant to mean
code has been copied.
> <5> src/util/array/nest.js
>
Note that this was src/util.nest.js. Same 'references to' issue.
> <6> src/scale/Time.js
>
Same 'references to' issue. Also says:
// Steps from d3, see the license statement at the top of this file.
which seems fine.
> <snip by bayard@>
>
> 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.
>
If it's originally a 3rd party file, then I'd encourage doing:
<Original license>
<Modifications by Apache eCharts provided under Apache License 2.0>
Hen
Re: License for using 3rd-party code
Posted by SHUANG SU <su...@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, 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, 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
Thanks,
Su Shuang
Re: License for using 3rd-party code
Posted by SHUANG SU <su...@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, 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, 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
Thanks,
Su Shuang
Re: License for using 3rd-party code
Posted by Justin Mclean <jm...@apache.org>.
Hi,
> 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.
> But we wish to know if this is complying with Apache's license.
It’s not about complying with the terms of the license it about following ASF policy on headers. (see above).
Thanks,
Justin
1. https://www.apache.org/legal/src-headers.html#3party
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: License for using 3rd-party code
Posted by Dave Fisher <da...@comcast.net>.
Hi Wenli -
I agree with Henry I don’t think we can best help ECharts unless you provide specific examples of (1) and (2).
Regards,
Dave
> On Jan 31, 2019, at 11:16 AM, Hen <ba...@apache.org> wrote:
>
> I’d caution this a little. “Inspired” is a very vague term.
>
> On Thu, Jan 31, 2019 at 10:13 AM Ralph Goers <ralph.goers@dslextreme.com <ma...@dslextreme.com>> wrote:
> You can be inspired all you want from other people’s work. There is no problem with copying ideas and no problems associated with that so long as the code is entirely yours and you aren’t violating the license of the inspirational work. You can just follow “normal” source code rules.
>
> But when you copy the code, even parts of files, it must remain under the copyright of the original authors. There are various ways to accomplish this depending on how messy you want to get.
>
> Ralph
>
>> On Jan 31, 2019, at 3:39 AM, Ovilia <oviliazhang@gmail.com <ma...@gmail.com>> wrote:
>>
>> Dear legal team,
>>
>> In our incubating ECharts project, we have some code that is inspired by 3rd-party libraries but may not use their code directly. I'd like to ask what should we do to the license headers of those files?
>>
>> 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.
>>
>> We'd prefer that ASF license header is attached at the top of the files, and annotations are commented at those positions that are inspired by 3rd-party libraries. But we wish to know if this is complying with Apache's license. Please give some advice.
>>
>> Zhang Wenli
>> http://zhangwenli.com <http://zhangwenli.com/>
Re: License for using 3rd-party code
Posted by Hen <ba...@apache.org>.
I’d caution this a little. “Inspired” is a very vague term.
On Thu, Jan 31, 2019 at 10:13 AM Ralph Goers <ra...@dslextreme.com>
wrote:
> You can be inspired all you want from other people’s work. There is no
> problem with copying ideas and no problems associated with that so long as
> the code is entirely yours and you aren’t violating the license of the
> inspirational work. You can just follow “normal” source code rules.
>
> But when you copy the code, even parts of files, it must remain under the
> copyright of the original authors. There are various ways to accomplish
> this depending on how messy you want to get.
>
> Ralph
>
> On Jan 31, 2019, at 3:39 AM, Ovilia <ov...@gmail.com> wrote:
>
> Dear legal team,
>
> In our incubating ECharts project, we have some code that is inspired by
> 3rd-party libraries but may not use their code directly. I'd like to ask
> what should we do to the license headers of those files?
>
> 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.
>
> We'd prefer that ASF license header is attached at the top of the files,
> and annotations are commented at those positions that are inspired by
> 3rd-party libraries. But we wish to know if this is complying with Apache's
> license. Please give some advice.
>
> Zhang Wenli
> http://zhangwenli.com
>
>
>
Re: License for using 3rd-party code
Posted by Ralph Goers <ra...@dslextreme.com>.
You can be inspired all you want from other people’s work. There is no problem with copying ideas and no problems associated with that so long as the code is entirely yours and you aren’t violating the license of the inspirational work. You can just follow “normal” source code rules.
But when you copy the code, even parts of files, it must remain under the copyright of the original authors. There are various ways to accomplish this depending on how messy you want to get.
Ralph
> On Jan 31, 2019, at 3:39 AM, Ovilia <ov...@gmail.com> wrote:
>
> Dear legal team,
>
> In our incubating ECharts project, we have some code that is inspired by 3rd-party libraries but may not use their code directly. I'd like to ask what should we do to the license headers of those files?
>
> 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.
>
> We'd prefer that ASF license header is attached at the top of the files, and annotations are commented at those positions that are inspired by 3rd-party libraries. But we wish to know if this is complying with Apache's license. Please give some advice.
>
> Zhang Wenli
> http://zhangwenli.com <http://zhangwenli.com/>
Re: License for using 3rd-party code
Posted by Justin Mclean <jm...@apache.org>.
Hi,
> 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.
> But we wish to know if this is complying with Apache's license.
It’s not about complying with the terms of the license it about following ASF policy on headers. (see above).
Thanks,
Justin
1. https://www.apache.org/legal/src-headers.html#3party
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@echarts.apache.org
For additional commands, e-mail: dev-help@echarts.apache.org