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>
