On 17/08/16 19:04, Ellison Anne Williams wrote: > From the discussion, although this seems to be somewhat murky ASF ground, > it seems that we need two sets of L&N files: > > 1.) L&N files to accompany executable jars, which include the transitive > L&N requirements dictated by the build (this is what our L&N files reflect > in PR 53)
Yes (with the caveat below). > 2.) L&N files to accompany source-only jars, which, in our case, would > really include only 'our' ASL L&N as we aren't distributing anything else > but our source Yes. > Is this correct? > > If so, from Billie's comments, it seems that we can accomplish this via > configuring our maven assembly plugin. We can make a 'assembly' directory, > include the source-only L&N files there, and configure accordingly. Is this > an acceptable practice? It needs to be the other way around, that is the L&N files in the _root_ of the Pirk repository should reflect our managed source code (i.e. (2) above), so that as people look at the repo, and clone it they see the correct L&Ns. The L&N files, accurately representing the results of building Pirk, can be pulled in from a subdirectory and appear in the root of the exe JAR [1]. At the moment, PR#65 is looking to put the binary L&N files into the top of the repository, and that is not correct. [1] or the META-INF/ dir if that is how we need to do it, but root would be preferable IMHO. Of course, the source L&Ns would not appear in the binary JARs. Regards, Tim > P.S. -- When I downloaded the NiFI source release here > https://www.apache.org/dyn/closer.lua?path=/nifi/1.0.0-BETA/nifi-1.0.0-BETA-source-release.zip > and checked the LICENSE and NOTICE files, I see the same files as in the > master branch on github -- am I completely missing something here? > > On Wed, Aug 17, 2016 at 11:53 AM, Billie Rinaldi <[email protected]> wrote: > >> It looks like it is also possible to have >> src/main/appended-resources/META-INF/LICENSE and >> src/main/appended-resources/META-INF/NOTICE that will be appended to the >> default. See https://issues.apache.org/jira/browse/ACCUMULO-3990 and these >> examples: >> >> https://github.com/apache/accumulo/tree/master/server/ >> monitor/src/main/appended-resources/META-INF >> https://github.com/apache/hbase/tree/master/hbase- >> thrift/src/main/appended-resources/META-INF >> >> This is for jars; it's also easy to adjust L&N for assemblies (tars and >> zips) because you're explicitly listing files to include in the assembly >> spec. >> >> On Wed, Aug 17, 2016 at 8:48 AM, Tim Ellison <[email protected]> >> wrote: >> >>> On 17/08/16 16:08, Ellison Anne Williams wrote: >>>> I'm seeing the same LICENSE and NOTICE files used throughout NiFi - >> even >>> in >>>> the nifi-assembly directory which is referenced here >>>> https://nifi.apache.org/licensing-guide.html >>> >>> FWIW the LICENSE I see in "nifi-1.0.0-BETA-source-release.zip" is quite >>> different to that in "nifi-1.0.0-BETA-bin.tar.gz". So they have figured >>> it out. >>> >>> Regards, >>> Tim >>> >>>> Joe - Am I missing something here? >>>> >>>> I would echo Suneel and ask if (1) it is really a strict requirement >> for >>>> our sources jar and/or (2) if we are interpreting it correctly. >>>> >>>> >>>> >>>> On Wed, Aug 17, 2016 at 10:55 AM, Suneel Marthi < >> [email protected] >>>> >>>> wrote: >>>> >>>>> On Wed, Aug 17, 2016 at 10:38 AM, Tim Ellison <[email protected]> >>>>> wrote: >>>>> >>>>>> On 17/08/16 11:40, ellisonanne wrote: >>>>>>> Github user ellisonanne commented on a diff in the pull request: >>>>>>> >>>>>>> https://github.com/apache/incubator-pirk/pull/65# >>>>>> discussion_r75099656 >>>>>>> >>>>>>> --- Diff: LICENSE --- >>>>>>> @@ -199,4 +199,64 @@ >>>>>>> distributed under the License is distributed on an "AS IS" >>>>> BASIS, >>>>>>> WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express >>> or >>>>>> implied. >>>>>>> See the License for the specific language governing >>> permissions >>>>>> and >>>>>>> - limitations under the License. >>>>>>> \ No newline at end of file >>>>>>> + limitations under the License. >>>>>>> + >>>>>>> + >>>>>>> +=========================================================== >>>>>> ============ >>>>>>> +Apache Pirk (incubating) Subcomponents: >>>>>>> + >>>>>>> +The Apache Pirk project contains subcomponents with separate >>>>>> copyright >>>>>>> +notices and license terms. Your use of the source code for the >>>>> these >>>>>>> +subcomponents is subject to the terms and conditions of the >>>>>> following >>>>>>> +licenses. >>>>>>> + >>>>>>> --- End diff -- >>>>>>> >>>>>>> I'm confused - how do we create different LICENSE and NOTICE files >>>>>>> for the different jars when they are built via the release plugin? >>>>>> >>>>>> I'm guessing it requires some pom foo beyond my feeble capabilities >> :-( >>>>>> >>>>> >>>>> I am not sure how u can package/not package license files in different >>>>> artifacts. >>>>> If this is a strict requirement, a good chunk of TLPs today are in >>>>> violation of this. >>>>> >>>>> Should we have Justin McLean or John D. Ament from IPMC review our >>>>> artifacts now? >>>>> >>>>>> >>>>>> Besides stating the obvious that : >>>>>> >>>>>> (1) we'd store the source LICENSE and NOTICE file in the project >>>>>> repository root, and place in there only the required information for >>>>>> code we are hosting in our repo and including in the source.jar. For >>>>>> Pirk as it is today, that will be a plain ALv2 text and simple >> notice. >>>>>> >>>>>> (2) we'd then have alternative LICENSE and NOTICE files for the >>>>>> convenience "exe" JAR in a subdirectory that are used to replace the >>>>>> top-level files when building the binaries. This would refer to the >>>>>> license/ directory containing the full text of the 3rd-party >> licenses. >>>>>> >>>>>> Maybe our friends from Apache NiFi can explain what they do, as they >>>>>> have the correct information in their release guide [1], and they are >>>>>> Maven-based too. >>>>>> >>>>>> A number of other projects I peeked into don't seem to be doing the >>>>>> right thing IMHO. >>>>>> >>>>>> [1] https://nifi.apache.org/licensing-guide.html >>>>>> >>>>>> Regards, >>>>>> Tim >>>>>> >>>>> >>>> >>> >> >
