There is a distinction. The dependencies_with_url.csv does manage to make sure our dependencies (and transitive dependencies) are appropriately accounted for. What we also need to do is make that any changes (if necessary) to the LICENSE and NOTICE files also make it in there. For example, certain attributions may be necessary in the NOTICE file. Similar things can happen with the LICENSE file (e.g. including licenses from dependencies from bundled code). It's possible that we don't have any problems, but I also expect that since we haven't been actively maintaining it that there might be issues. E.g. if the UI has pulled in anything bundled in our source, modifications to the L&N may need to be made.
As far as uberjars go, I believe we're fine. Like you said, we aren't distributing them, so they aren't bundled. Otto, you mentioned on Slack that NiFi requires some checking in having PRs reviewed and in reviewing PRs. Could you share your experience there? On Wed, Sep 12, 2018 at 1:36 PM Otto Fowler <ottobackwa...@gmail.com> wrote: > Are you referring to the dependencies check against the csv? > > > On September 12, 2018 at 13:09:48, Michael Miklavcic ( > michael.miklav...@gmail.com) wrote: > > I'm not sure I fully understand what is out of date. I know I have > personally modified our licenses a couple times in the past and used an > automated script that, I believe, Casey Stella had created for doing the > check. I even made some improvements to it a long ways back. It rips > through the maven dependency tree and tells you what isn't in the licenses > file and fails with a non-zero return code. I thought that was part of our > Travis build, or at the very least, the release lifecycle. Is that not the > case, or is there a different context we're talking about here? > > I understand that convenience binaries might some issues with uberjars when > we go that route for 1.0. But is there any issue with the uberjars as > things currently stand? I was under the impression we are OK because we > don't distribute them. It's part of the build, just like tools such as > JUnit, that we don't actually ship. > > Justin - These are the links for guidance that I've found. Is anything else > you've found that we should peruse while figuring this out? > > - https://www.apache.org/dev/licensing-howto.html > - http://www.apache.org/legal/release-policy.html#artifacts > > Mike > > > On Wed, Sep 12, 2018 at 10:29 AM Justin Leet <justinjl...@gmail.com> > wrote: > > > Hi all, > > > > As mentioned on the release voting thread, there was a Slack discussion > > around our LICENSE and NOTICE file likely being outdated because they > > haven't been actively kept up to date since graduation. I suggested on > the > > vote thread that we proceed with the current release, but consider it a > > blocker for the next release. > > > > Mentor input on this (and how other projects handle it), would be greatly > > appreciated. > > > > This discussion should result in JIRAs that are brought back to the > thread, > > so we can make sure to track this. > > > > For context, in addition to the standard L&N management, when we build > > artifacts we shade a lot of jars into a uberjars, thus bundling > > dependencies. However, our current releases are source only, but > > publishing convenience binaries came up in the 1.0 roadmap thread. > > > > I think there are a few things that need to happen to correct our current > > issue and make this easier in the future. > > 1) Get the LICENSE and NOTICE files up to date > > 2) Document the process we went through getting things up to date and > (just > > as importantly) the reasoning behind it. > > 3) Update the PR checklist to include LICENSE and NOTICE files for new > (and > > transitive) dependencies. > > 4) Update or add any processes we need to maintain this properly (e.g. > > release auditing) > > 5) Possibly build tooling for making some of this auditing easier (or use > > existing tool if anyone has suggestions)? > > > > Are there any other steps I'm missing that need to go into JIRAs? > > Any other concerns regarding these files that need to be addressed? > > Any other context I'm missing and that belongs in this discussion? > > >
