@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" <s...@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: s...@us.ibm.com,
Phone: +1(919)254-7182
Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703,
United States
-----Julian Hyde <jh...@apache.org> wrote: -----
To: general@incubator.apache.org
From: Julian Hyde <jh...@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 <aha...@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" <peppe...@japf.ch
<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 +0000
"Vincent S Hou" <s...@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: s...@us.ibm.com,
Phone: +1(919)254-7182
Address: 4205 S Miami Blvd (Cornwallis Drive), Durham, NC 27703,
United States
-----"Jonas Pfefferle" <peppe...@japf.ch> wrote: -----
To: "general@incubator.apache.org" <general@incubator.apache.org>
From: "Jonas Pfefferle" <peppe...@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-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
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
<mailto:general-unsubscr...@incubator.apache.org>
For additional commands, e-mail: general-h...@incubator.apache.org
<mailto: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
