Re: Update copyright dates not handled by scripts/update-copyrights [committed]

[Torvald Riegel <triegel@redhat.com>]

On Mon, 2017-01-02 at 17:19 +0000, Joseph Myers wrote:
> On Mon, 2 Jan 2017, Torvald Riegel wrote:
> 
> > > The newer logs are a matter of the GNU Coding Standards.  That is, if you 
> > > don't want to maintain information about "what" changed in that particular 
> > > form, you should be persuading the GCS maintainers to allow just logging 
> > > descriptions of what and why changed at the logical level rather than the 
> > > level of individual files and functions (in the case where a version 
> > > control system provides tracking of the "what" ... not all GNU packages 
> > > have public version control).
> > 
> > Are you saying that from your point of view, GCS is the only significant
> > reason for maintaining changelogs?
> 
> My suggestion is that it would be reasonable to argue to the GCS 
> maintainers that ChangeLog-format logs need not be maintained for a 
> package for which all of the following are true:
> 
> * it has public version control,
> 
> * in a distributed VCS,
> 
> * where commits are made for each logical change, not batched into a 
> commit per release (see bash for an example of such batching) or per day 
> or other such batching,
> 
> * with authors not just committers tracked,
> 
> * with commit messages describing the logical "what" changed (but not 
> describing the physical "what" at the level of changes to individual files 
> and functions).
> 
> That is, when all the above are true, the information about changes is 
> more usefully available through the VCS than through ChangeLog-style 
> messages and people wanting that information will be expecting to go to 
> the VCS for it rather than to find it in the release tarballs, so 
> ChangeLog-style messages can be considered obsoleted by the VCS in that 
> case (and in that case, the GCS requirements for ChangeLog files do not 
> serve a useful technical purpose -

Thanks.  That's a useful ruleset.

> this is a separate matter from any 
> legal reasons there might be for including such information about changes 
> and their authorship in release tarballs).
> 
> > Maybe we should just announce that we'll stop doing changelogs and see
> > whether anybody complains.  If people complain, it would be interesting
> 
> That's not an appropriate way to work for a GNU package.  We need to work 
> with the GNU project (and quite possibly, the FSF in turn work with their 
> lawyers to establish if there are any legal reasons relating to 
> attribution of changes within releases).

So, who should this go to at the FSF side?  maintainers@gnu.org?

Do you want to start this discussion?  Or can I just copy-and-paste what
you wrote above?

Do we have consensus in glibc that aside from any legal considerations
regarding attribution (an important point you made, thanks), we'd like
to have a rule like the one you proposed above in place so we don't have
to maintain changelogs?

Regarding the legal considerations, do we need anything else beyond the
FSF's opinion on this?