incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <jh...@apache.org>
Subject Re: licenses and copyrights of dependencies
Date Wed, 07 Nov 2018 17:43:06 GMT
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&amp;data=02%7C01%7Caharui%40adobe.com%7C22616922cce64b8fc10a08d644cb21ff%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636772036594764319&amp;sdata=5MSLi36WDsEVlzgZxdUpPmUmFP0PIh0upgPgVsRmJnU%3D&amp;reserved=0
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23distribute-other-artifacts&amp;data=02%7C01%7Caharui%40adobe.com%7C22616922cce64b8fc10a08d644cb21ff%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636772036594764319&amp;sdata=5MSLi36WDsEVlzgZxdUpPmUmFP0PIh0upgPgVsRmJnU%3D&amp;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>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message