incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonas Pfefferle" <peppe...@japf.ch>
Subject Re: licenses and copyrights of dependencies
Date Thu, 08 Nov 2018 08:26:14 GMT
@Alex @Julian ok, I understand the convenience argument.
@Vincent thanks for the input, the licenses in an extra folder is certainly 
an option to consider.

@Justin I understand the need for this to be transitive but what if the 
artifact has contracting licenses, e.g. as mentioned BSD-c2 vs BSD-c3? I 
assume it is not our problem to figure this out but just put whatever is in 
there in our LICENSE file?

Thanks,
Jonas

  On Wed, 7 Nov 2018 20:51:44 +0000
  "Vincent S Hou" <shou@us.ibm.com> wrote:
> I used to use and also see some other projects use the following 
>structure to maintain the third-party license:
> Create a folder licenses under root to hold the licenses of the 
>dependencies, like lib1.txt with the content of lib1 license, and 
>lib2.txt with the license content of lib2.
> 
> In your LICENSE file under root, you can use statement like "This 
>project/module has a binary dependency on lib1, with its license 
>available in licenses/lib1.txt...". As long as you have correct 
>description about the relationship with the third-party library. It 
>should be fine.
> 
> Again, for source code release, it is OK without saying the 
>relationship and pointing to the licenses, because users only grab 
>your source code with the correct apache license 2.0. You do not ship 
>the libraries you depend on in your artifacts, but you can tell the 
>users they can download them from somewhere to run your project. 
>After they download it, it is their responsibility to get the correct 
>dependencies, build and run your project. To me, no matter what they 
>do, how they use and build, are technically out of your scope, 
>because it is not under the brand of apache. Even if they run into 
>legal issues, it will be their problems. 
> 
> But for binary release, you need to say the artifact you ship 
>depends on these these libraries with the licenses, since the 
>artifact is built based on them, and is made available under the 
>brand of apache.
> 
> This is actually my understanding about shipping the code and 
>binaries.
> 
> Best wishes.
> Vincent Hou (侯胜博)
> 
> Advisory Software Engineer, OpenWhisk Contributor, Open Technology, 
>IBM Cloud
> 
> Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: shou@us.ibm.com,
> Phone: +1(919)254-7182
> Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, 
>United States
> 
> -----Julian Hyde <jhyde@apache.org> wrote: -----
> To: general@incubator.apache.org
>From: Julian Hyde <jhyde@apache.org>
> Date: 11/07/2018 12:43PM
> Subject: Re: licenses and copyrights of dependencies
> 
> What Alex is saying makes sense. Whether you like it or not, you are 
>creating a derived work (or something - I am not a lawyer), and that 
>needs its own L&N.
> 
> 
>> On Nov 7, 2018, at 9:03 AM, Alex Harui <aharui@adobe.com.INVALID> 
>>wrote:
>> 
>> IIRC, we use the food allergy analogy for these situations.  AIUI, 
>>the goal is for the top-level LICENSE to make it convenient for 
>>someone to see what the ingredients are, because some folks are 
>>"allergic" to certain licenses.  I think you can still use "pointers" 
>>instead of copying full texts of licenses, but having people open jar 
>>files to read the licenses seems to defeat the "convenience" of 
>>reading the ingredients.  If your packaging can extract a LICENSE 
>>from each jar you could point to those files.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 11/7/18, 8:07 AM, "Jonas Pfefferle" <pepperjo@japf.ch 
>><mailto:pepperjo@japf.ch>> wrote:
>> 
>>    Hi Vincent,
>> 
>> 
>>    At least right now we have the source code part covered since we 
>>do not ship 
>>    any third party code/jars etc. with it. However, as you pointed 
>>it is a 
>>    concern for the binary release. We just want this to be easy to 
>> manage. At 
>>    the moment we have 80+ jars that we ship as dependencies in the 
>>binary 
>>    release. As pointed out before all of them have the license at 
>>least 
>>    mentioned in the pom or have a license file in META-INF. Best 
>>case scenario 
>>    we could just list all jars in the LICENSE file and refer to 
>>their license 
>>    in the jar instead of copying everything. This makes it much 
>>easier to 
>>    add/remove dependencies or change versions...
>>    Does this make sense?
>> 
>>    Thanks,
>>    Jonas
>> 
>>      On Wed, 7 Nov 2018 15:56:45 +0000
>>      "Vincent S Hou" <shou@us.ibm.com> wrote:
>>> Hi Jonas,
>>> 
>>> I totally understand your situation right now, because I have just 
>>> gone through the release process for my project Apache OpenWhisk as 
>>> well.
>>> 
>>> Regarding whether you should add the copyright, to me, it depends on 
>>> the source code release or the binary release.
>>> If you only care about the source code release, you can only focus 
>>> on the "SOURCE CODE". For example, if one or some of your SOURCE 
>>>CODE 
>>> come from another library with a certain copyright, you should add 
>>>it 
>>> into your LICENSE file. If your code depends on jar or any other 
>>> packages shipped by other parties, you do not need to add their 
>>> copyright into your LICENSE, because your source code release do not 
>>> and should not include any jar or packages. You can document 
>>> somewhere that these jars or packages are dependencies to run your 
>>> code.
>>> 
>>> If you come to binary release, and all the dependencies play a role 
>>> in order to compile your source code, you need to have the LICENSE 
>>> file with all the copyright for the dependencies.
>>> 
>>> In a nutshell, source code release is relatively easier to edit your 
>>> LICENSE, but binary release may be a hassle. 
>>> 
>>> For folks with different comments, welcome to chime in.
>>> 
>>> 
>>> Best wishes.
>>> Vincent Hou (侯胜博)
>>> 
>>> Advisory Software Engineer, OpenWhisk Contributor, Open Technology, 
>>> IBM Cloud
>>> 
>>> Notes ID: Vincent S Hou/Raleigh/IBM, E-mail: shou@us.ibm.com,
>>> Phone: +1(919)254-7182
>>> Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, 
>>> United States
>>> 
>>> -----"Jonas Pfefferle" <pepperjo@japf.ch> wrote: -----
>>> To: "general@incubator.apache.org" <general@incubator.apache.org>
>>> From: "Jonas Pfefferle" <pepperjo@japf.ch>
>>> Date: 11/07/2018 07:35AM
>>> Subject: licenses and copyrights of dependencies
>>> 
>>> Hi all,
>>> 
>>> 
>>> We are just preparing a new release and are wondering how and what 
>>> is 
>>> required for licenses and copyrights of components shipped with an 
>>> artifact. 
>>> According to the release 
>>> policy 
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23distribute-other-artifacts&data=02%7C01%7Caharui%40adobe.com%7C22616922cce64b8fc10a08d644cb21ff%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636772036594764319&sdata=5MSLi36WDsEVlzgZxdUpPmUmFP0PIh0upgPgVsRmJnU%3D&reserved=0

>>><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23distribute-other-artifacts&data=02%7C01%7Caharui%40adobe.com%7C22616922cce64b8fc10a08d644cb21ff%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636772036594764319&sdata=5MSLi36WDsEVlzgZxdUpPmUmFP0PIh0upgPgVsRmJnU%3D&reserved=0>
>>> 
>>> we need to include licenses of all components shipped in an 
>>> artifact. The 
>>> example just appends all licenses to the LICENSE file including the 
>>> copyrights. Is the copyright required? Shouldn't the copyright be 
>>> appended 
>>> to the NOTICE file instead?
>>> 
>>> Also we found that some artifacts have contradicting or missing 
>>> licenses 
>>> e.g. in the pom of one artifact a BSD clause 2 license is mentioned 
>>> but no 
>>> LICENSE files are shipped in the jars, however the source contains a 
>>> BSD 
>>> clause 3 license.
>>> 
>>> Thanks,
>>> Jonas
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>> 
>> 
>>    ---------------------------------------------------------------------
>>    To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>    For additional commands, e-mail: 
>>general-help@incubator.apache.org
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org 
>><mailto:general-unsubscribe@incubator.apache.org>
>> For additional commands, e-mail: general-help@incubator.apache.org 
>><mailto:general-help@incubator.apache.org>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
> 





---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message