So, here is what I ended up doing: 1.) Changing the root LICENSE and NOTICE files to be the source-only Pirk L&N files
2.) Creating a src/main/resource/META-INF/bin-license-notice directory containing the L&N files corresponding to the binary distribution of Pirk -- LICENSE-bin and NOTICE-bin 3.) Moving the 'licenses' directory to src/main/resource/META-INF/bin-license-notice/licenses so that the full licenses are available in the binary artifacts Thus, all of the L&N files are available under META-INF for both the source and binary distributions and are labeled accordingly. You can check by running: mvn clean release:clean mvn -Psigned_release release:prepare -Darguments="-DskipTests" and then checking the jar files. Mentors - correct me if I'm wrong, but the rules just state the the correct L&N files should be included in the appropriate distributions, not that we can't have the binary L&N files in the source dist as long as we label them as such (they are in their own directory labeled as 'bin-license-notice'). I will be the first to say that this is not the most elegant solution -- I will put in a JIRA issue to make this more elegant and to have the binary L&N files appear at the root of the binary artifacts. Hopefully, in the interim, it satisfies our L&N compliance. On Thu, Aug 18, 2016 at 4:06 AM, Tim Ellison <[email protected]> wrote: > On 17/08/16 19:59, Ellison Anne Williams wrote: > > Thanks guys. > > > > I will make another set of L&N files (other than what's in the root of PR > > 53) for the source-only release artifacts and figure out where to place > > them based on the previous comments. I will add them to PR 53, so let's > not > > merge yet (I will change the status to WIP)... > > Please see my other note, and let's put the source L&N at root, and the > binaries into a subdirectory for use during building. > > > I want to make sure that we follow the correct ASF procedures for L&N > files > > (whatever time that it takes) and get it as 'right as possible' with the > > first release. > > You're doing a fantastic job! I know this is real pain to do, > especially as it doesn't have a technical impact, but it is important. > As you can see even many top level projects are not doing it right > (yet). Consumers of Pirk need a clear picture of what they are > receiving and their obligations, so thank you for stepping up to sort it > out! > > Regards, > Tim > > > > On Wed, Aug 17, 2016 at 2:41 PM, Billie Rinaldi <[email protected]> > wrote: > > > >> Every artifact needs L&N files, so the source release zip and jars all > need > >> their own L&N. Perhaps the L&N would be the same for the zip and > >> source-only jars (depending on the exact contents), while the exe jar > would > >> need a different L&N. > >> > >> I believe the assembly plugin only creates the zip, and some other > plugin > >> creates the jars. Possibly the jar plugin, or the remote resources > plugin > >> might be involved (based on the comment in the parent pom: > >> http://svn.apache.org/repos/asf/maven/pom/trunk/asf/pom.xml). Either > way, > >> it seems like changing the plugin configuration might not be necessary > to > >> modify L&N in jars; we may just be able to drop in the L&N in a META-INF > >> directory in src/main/resources or src/main/appended-resources (as in > the > >> examples linked in Joe's and my previous emails). As for the source > release > >> zip, the L&N from the main project directory will be used. > >> > >> On Wed, Aug 17, 2016 at 11:04 AM, Ellison Anne Williams < > >> [email protected]> 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) > >>> > >>> 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 > >>> > >>> 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? > >>> > >>> > >>> > >>> 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 > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > >
