Gunnar, it is largely irrelevant based on the legal expertise we have been given by Red Hat. But if you are going to keep up with it (and I think there is value to that, and do it myself still) generally the year should just be touched for non-trivial updates. A range is good. Simply updating the year to the current year is fine. Listing years of all such non-trivial updates is yet another good approach. Personally I tend to just update the year.

Hi, if there is no strong legal constraint for this, we might also always simply specify the range "year of inception - current year". This could be automated using the Maven license plugin [1], which can add/update headers for all sources based on a template and also fail the build if there is a file without correct header. Compared to updating headers individually when changing a file, I think that would be simpler from a developer's perspective and also reduce the risk of forgetting headers, copying old ones etc. --Gunnar [1] http://code.google.com/p/maven-license-plugin/ Am 13. April 2012 10:38 schrieb Hardy Ferentschik<hardy(a)hibernate.org>: > > On Apr 13, 2012, at 12:16 AM, Steve Ebersole wrote: > >> Gunnar, it is largely irrelevant based on the legal expertise we have >> been given by Red Hat. >> >> But if you are going to keep up with it (and I think there is value to >> that, and do it myself still) generally the year should just be touched >> for non-trivial updates. A range is good. Simply updating the year to >> the current year is fine. Listing years of all such non-trivial >> updates is yet another good approach. Personally I tend to just update >> the year. > > +1 My preference is also to just update the year. > > --Hardy > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev