On 04/25/2016 06:14 PM, Tom Rini wrote:
On Mon, Apr 25, 2016 at 05:34:55PM -0600, Stephen Warren wrote:
On 04/25/2016 05:26 PM, Tom Rini wrote:
On Mon, Apr 25, 2016 at 05:11:16PM -0600, Stephen Warren wrote:
On 04/25/2016 05:05 PM, Tom Rini wrote:
On Mon, Apr 25, 2016 at 04:43:34PM -0600, Stephen Warren wrote:
On 04/25/2016 04:37 PM, Tom Rini wrote: > On Mon, Apr 25, 2016 at 11:52:53PM +0200, Wolfgang Denk wrote: >> Dear Stephen Warren, >> >> In message 571E733A.1060208@wwwdotorg.org you wrote: > [snip] >>> Unfortunately we've (NVIDIA at least) been a little lax making sure the >>> NVIDIA copyright messages are kept up-to-date when editing files, hence >>> why this series had to change a lot of them for the first time recently. >>> If we went back and re-wrote all of git history paying strict attention >>> to the copyright notice dates and formatting, I imagine the set of >>> copyright-related changes in this series would be much smaller. > > I'm quoting Wolfgang's email here, but, yes, keeping the copyright > notices correct is important. Now, what do you mean by would be > smaller?
Personally I want to spend my time coding rather than dealing with licensing. As such, it's easy to forget to update the dates in copyright notices when changing files, or to put the correct information into new files when creating new ones (often by just cutting/pasting some other file with similar issues). If we had done that 100% correctly in every commit across history, my inclination is that more files would already have an NVIDIA copyright message, and/or already have 2016 in the date, and hence this series wouldn't include an edit to those messages since they'd already be up-to-date. Still, I have no searched all history to confirm that; it's just my gut instinct.
Right, OK. So you're saying you may, in some cases, be adding 2016 to files you haven't touched this year yet?
Yes, I'm sure there's a mix.
OK. And I assume you're globbing on file paths to check / update? Doing you can do 'git log --since=YYYY-01-01-YYYY-12-31' to find the first/last commits in a given year, git diff a..b | diffstat > Y.txt to get a diffstat and check your numbers vs that. This doesn't feel like an undue burden on making sure copyright stuff is year-correct for last-touch.
Well, by "yet" I assumed you mean "before this patch set". There are no changes in the patch set that do nothing but edit/add a copyright notice without making other changes. The only edits to copyrights in this series are because I've edited files for the purpose behind the patch, and then have updated the copyright while doing so.
What I did was: a) Make all the changes. b) Go through all the patches with "git rebase -i", get the list of files edited in the patch, and ensure the copyright date reflected the edit made in that patch.
OK. This should make any quick sanity checks easier, rather than harder. Generate the lists, diffstat your series, for F in series, grep -q year-list && echo touched $F;done
BTW, while code re-org is not the most involved of coding, I don't see a reason to make developers decide legal issues such as what amounts to a change that's large enough to change the copyright date, or add a copyright header. The rule should be simple and unambiguous (edit a file -> change the copyright); anything else is asking for different people to argue over interpretation, which just everybody's wastes time. Let's leave that to lawyers and just deal with code.
I agree in spirit, with a caveat about meeting a significance threshold. I think you need to push back on your legal department if they are asking that every change requires a copyright notice, regardless of length or complexity. I _cannot_ start having patches conflict because the contents are fine but now I have to fixup the copyright notices added since the patch was generated,
I'm not sure why. Let's say the two conflicting patches are both unambiguously significant works, by two different people/entities. Surely there's no issue with the copyright notices both being added/updated in that case? If so, then the only difference is the volume of conflicts. Volume doesn't seem a great argument since it's not a problem with the core issue itself.