On Tue, Apr 26, 2016 at 10:21:08AM -0600, Stephen Warren wrote: > 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 <[email protected]> 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.
The problem here is that much of this series is not making unambiguously significant changes. I do not have a problem with (but maybe I need to chat with the Software Freedom Conservancy folks more) adding / extending copyrights when adding significant changes to existing files nor adding them to new files. -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
