Update copyright years to 2015 about ros2

[esteve]

Sounds good.

[dirk-thomas]

You don't want to apply this to the existing files - only to new ones, right?

Most of the existing code was developed in 2014.

[wjwwood]

@dirk-thomas you're probably right. I'll go through and make sure any modified files have the right year, untouched files I'll leave alone. I think the change on write policy is appropriate.

Ideally, we could setup a post install hook which checks that the year is right in changed files on commit. Or a unit test which looks at the last modified date of each file and checks against the copyright year in the file, if it has one. It's pretty low priority, but I think it actually might be pretty easy to do.

[dirk-thomas]

I don't think that we should ever remove a copyright year but only include the current year on change.

See http://stackoverflow.com/questions/3487007/when-to-update-the-year-in-open-source-copyright-notice for similar questions.

[wjwwood]

Ok, that works for me too, I'll go through and check that the existing files which were created in 2015 have the right year, others which were created in 2014 have that year. Additionally, if the files were created in 2014, but modified in 2015 that they include both.

I think a tool to check this is sounding better all the time. Again, low priority.

[dirk-thomas]

The functionality could be added to the linter package ament_copyright. It would be great if it can not only check the code but also update it if necessary.

[wjwwood]

I agree, however, I will say that tools that automatically change my code annoy me. For example, in the Tango project there is a post commit hook that runs everything through clang-format and automatically updates the commit. This was incredibly frustrating and it made my commits messier than they needed to be, mixing style changes with code changes.

I would prefer tools like this tell me there is a problem (ideally as a test failure) and then give me a command I can run to fix it automatically or explicitly skip testing for that instance.

[dirk-thomas]

All current linter packages provide the feedback what needs to change.

But some of them also have a command line option to perform the recommended modifications. I consider that a very helpful option to not waste time if the tool has already figured out what needs to be changed.

[wjwwood]

Another item, make sure the actual snippet is consistent: ament/ament_lint#3 (comment)

[wjwwood]

@esteve, use the tool if possible.

[dirk-thomas]

I think this has been addressed while adding all the missing copyright / license information as part of ament/ament_lint#15 (comment)
I tried to use reasonable year ranges where ever possible from looking at the git history.

[wjwwood]

Sounds good to me.