octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Maintaining Copyright notices


From: Rik
Subject: Re: Maintaining Copyright notices
Date: Fri, 3 Jan 2020 16:28:36 -0800

On 01/03/2020 04:11 PM, address@hidden wrote:
> The Octave source files currently contain copyright notices that list
> individual contributors.  I adopted these file-scope copyright notices
> because that is what everyone was doing 30 years ago in the days before
> distributed version control systems.  But now, with many contributors and
> modern version control systems, having these file-scope copyright notices
> causes trouble when we update copyright years or refactor code.
>
> Over time, the file-scope copyright notices may become outdated as new
> contributions are made or code is moved from one file to another.
> Sometimes people contribute significant patches but do not add a line
> claiming copyright.  Other times, people add a copyright notice for their
> contribution but then a later refactoring moves part or all of their
> contribution to another file and the notice is not moved with the code. 
> As a practical matter, moving such notices is difficult -- determining
> what parts are due to a particular contributor requires a time-consuming
> search through the project history.  Even managing the yearly update of
> copyright years is problematic.  We have some contributors who are no
> longer living.  Should we update the copyright dates for their
> contributions when we release new versions?  Probably not, but we do
> still want to claim copyright for the project as a whole.
>
> To minimize the difficulty of maintaining the copyright notices, I would
> like to change Octave's sources to use what is described here
>
>
> https://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
>
> in the section "Maintaining centralized copyright notices":
>
>   The centralized notice approach consolidates all copyright
>   notices in a single location, usually a top-level file.
>   This file should contain all of the copyright notices
>   provided project contributors, unless the contribution was
>   clearly insignificant. It may also credit—without a copyright
>   notice—anyone who helped with the project but did not
>   contribute code or other copyrighted material.
>
>   This approach captures less information about contributions
>   within individual files, recognizing that the DVCS is better
>   equipped to record those details. As we mentioned before, it
>   does have one disadvantage as compared to the file-scope
>   approach: if a single file is separated from the distribution,
>   the recipient won’t see the contributors’ copyright notices.
>   But this can be easily remedied by including a single
>   copyright notice in each file’s header, pointing to the
>   top-level file:
>
>     Copyright YYYY-YYYY The Octave Project Developers
>
>     See the COPYRIGHT file at the top-level directory
>     of this distribution or at https://octave.org/COPYRIGHT.html.
>
> followed by the usual GPL copyright statement.
>
> The COPYRIGHT file would also point to the COPYING file and the AUTHORS
> file.  A draft version of that file is attached.  I created it from
> Mercurial history and old ChangeLog files (for even older changes).  I
> did not generate it directly from the Copyright lines in current source
> files because those lines have things like copyright years updated just
> because we were updating years and those dates have nothing to do with
> the years people actually made contributions.  I'd rather avoid
> propagating the mistake of updating copyright years for people who are no
> longer contributing (possibly because they are dead).
>
> In the future, we will update copyright years for each contributor listed
> in the COPYRIGHT file.  If we are doing that from Mercurial history each
> year, then it seems easier than attempting to do it for each source file.
>
> Then the guidelines for updating copyright info each year would be
> something like
>
>   * Update the dates the copyright statements of each file
>     so that all source files list the current year.  I believe
>     this is justified because the Octave developers are claiming
>     copyright for the project as a whole and we publish a version
>     during the current year (even without a formal release, the
>     sources are published on the web always).
>
>   * Update the dates in the COPYRIGHT file for anyone who
>     contributed some change during the year.  It should be
>     easy to generate a list of contributors from the hg history
>     and fairly easy to match them up with previous contributors
>     listed in the COPYRIGHT file.  Should we also try to skip
>     trivial changes?  If so, then maybe we should make it
>     possible to automate this job by tagging such changes with a
>     "[trivial change]" marker in the commit message.

I support this.  In fact, this system seems likely to lead to better
attribution.

I personally don't see the need to distinguish between a trivial change and
all other changes.  It would be hard to establish an objective standard
anyways (are typos in the documentation trivial or not?) so I just wouldn't
bother.   

>
> Should the COPYRIGHT file include email addresses with the names?  For
> now, I have them as <...> in the attached copy but the original version
> that I created includes the full addresses.

I don't think e-mail addresses should be included.  There is no requirement
to do so in order to claim copyright, so we might as well err on the side
of protecting privacy.

>
> Additionally, I think it is time to drop the "Author:", "Created:",
> "Adapted-by:" and similar lines that appear in some source files since
> that information is incomplete, tends to become inaccurate over time, and
> is duplicated in the version control system (where it is also most likely
> to be correct).

I would love to see this clutter removed since it is far better represented
in the history logs of Mercurial.

--Rik






reply via email to

[Prev in Thread] Current Thread [Next in Thread]