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
