Re: licenses and copyrights of dependencies

[Justin Mclean]

Hi,

> @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?=

I would probably put both in the LICENSE file, but would need to look at the 
actual code to work out what to do.

Thanks,
Justin

Re: licenses and copyrights of dependencies

[Jonas Pfefferle]

@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 +
 "Vincent S Hou"  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: s...@us.ibm.com,
Phone: +1(919)254-7182
Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, 
United States


-Julian Hyde  wrote: -
To: general@incubator.apache.org
From: Julian Hyde 
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



On Nov 7, 2018, at 9:03 AM, Alex Harui  
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" <mailto:peppe...@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 +
 "Vincent S Hou"  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

Re: licenses and copyrights of dependencies

[Vincent S Hou]

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: s...@us.ibm.com,
Phone: +1(919)254-7182
Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United States

-Julian Hyde  wrote: -
To: general@incubator.apache.org
From: Julian Hyde 
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




> On Nov 7, 2018, at 9:03 AM, Alex Harui  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"  <mailto:peppe...@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 +
>  "Vincent S Hou"  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 al

Re: licenses and copyrights of dependencies

[Justin Mclean]

Hi,

> 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?

If the license include it and the terms of the license say so then yes. This 
applied to common permissive licenses like MIT and BSD.

> Shouldn't the copyright be appended to the NOTICE file instead?

In general no, only relocated copywriter statements (i.e those removed from 
source headers) need to be in NOTICE. This is usually the company listed in the 
software grant to the ASF.

> 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.

Often you find extra things bundled inside under different licenses so they 
must be included as well. For example jQuery included MIT licensed Sizzle.js.

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: licenses and copyrights of dependencies

[Julian Hyde]

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




> On Nov 7, 2018, at 9:03 AM, Alex Harui  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"  > 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 +
>  "Vincent S Hou"  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: s...@us.ibm.com,
>> Phone: +1(919)254-7182
>> Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, 
>> United States
>> 
>> -"Jonas Pfefferle"  wrote: -
>> To: "general@incubator.apache.org" 
>> From: "Jonas Pfefferle" 
>> 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-artifactsdata=02%7C01%7Caharui%40adobe.com%7C22616922cce64b8fc10a08d644cb21ff%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636772036594764319sdata=5MSLi36WDsEVlzgZxdUpPmUmFP0PIh0upgPgVsRmJnU%3Dreserved=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
>> 
>> 
>> 

Re: licenses and copyrights of dependencies

[Alex Harui]

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"  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 +
  "Vincent S Hou"  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: s...@us.ibm.com,
> Phone: +1(919)254-7182
> Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, 
>United States
> 
> -"Jonas Pfefferle"  wrote: -
> To: "general@incubator.apache.org" 
>From: "Jonas Pfefferle" 
> 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-artifactsdata=02%7C01%7Caharui%40adobe.com%7C22616922cce64b8fc10a08d644cb21ff%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636772036594764319sdata=5MSLi36WDsEVlzgZxdUpPmUmFP0PIh0upgPgVsRmJnU%3Dreserved=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-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org
> 

Re: licenses and copyrights of dependencies

[Jonas Pfefferle]

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 +
 "Vincent S Hou"  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: s...@us.ibm.com,
Phone: +1(919)254-7182
Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, 
United States


-"Jonas Pfefferle"  wrote: -
To: "general@incubator.apache.org" 
From: "Jonas Pfefferle" 
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 
http://www.apache.org/legal/release-policy.html#distribute-other-artifacts


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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org


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





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

Re: licenses and copyrights of dependencies

[Vincent S Hou]

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: s...@us.ibm.com,
Phone: +1(919)254-7182
Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703, United States

-"Jonas Pfefferle"  wrote: -
To: "general@incubator.apache.org" 
From: "Jonas Pfefferle" 
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 
http://www.apache.org/legal/release-policy.html#distribute-other-artifacts

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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




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

Re: licenses and copyrights of dependencies

[Bertrand Delacretaz]

Hi,

On Wed, Nov 7, 2018 at 1:35 PM Jonas Pfefferle  wrote:
> ...Shouldn't the copyright be appended
> to the NOTICE file instead?...

Probably not - the NOTICE must be minimal as per
http://www.apache.org/dev/licensing-howto.html we must only add "any
*mandatory* legal notifications specific to the IP of your product to
NOTICE".

It's probably easier to just follow the examples on the release policy page.

-Bertrand

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

Re: licenses and copyrights of dependencies

[Adrian Schuepbach]

Hi all

I think this is a good idea. Rather than copying all licenses and
then ship both, the original license in each jar and the copied
one, I would prefer to list the jars in the NOTICE file and point
to the licenses already included in the listed jars.

The advantages are that (1) the project's own LICENSE file
stays readable and shorter while still all licenses are included in the
respective jars, (2) there is no unnecessary
replication of the same license files, (3) it is more consistent,
as there are not multiple versions of the same license
and (4) it is more manageable, especially for dependencies,
which are not Apache and which have their own (non-standardized)
way of handling licenses.

For these reasons I would prefer to list the dependencies
and explicitly state that their licenses are contained there.

Thanks
Adrian






From:   "Jonas Pfefferle" 
To: general@incubator.apache.org
Date:   11/07/2018 01:52 PM
Subject:    Re: licenses and copyrights of dependencies



Since we are only shipping jars and jars already include the licenses e.g. 

in META-INF or the pom file, we could refer to them in the NOTICE file 
instead of replicating them.


Jonas

  On Wed, 07 Nov 2018 13:35:04 +0100
  "Jonas Pfefferle"  wrote:
> 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 
http://www.apache.org/legal/release-policy.html#distribute-other-artifacts

> 
> 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-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org
> 



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

Re: licenses and copyrights of dependencies

[Jonas Pfefferle]

Since we are only shipping jars and jars already include the licenses e.g. 
in META-INF or the pom file, we could refer to them in the NOTICE file 
instead of replicating them.



Jonas

 On Wed, 07 Nov 2018 13:35:04 +0100
 "Jonas Pfefferle"  wrote:

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 http://www.apache.org/legal/release-policy.html#distribute-other-artifacts


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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org





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