[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
- Maintaining copyright notices, John W. Eaton, 2020/01/03
- Re: Maintaining copyright notices, Andrew Janke, 2020/01/03
- Re: Maintaining copyright notices, Ben Abbott, 2020/01/03
- Re: Maintaining copyright notices, Mike Miller, 2020/01/04
- Re: Maintaining copyright notices, Torsten Lilge, 2020/01/04
- Re: Maintaining copyright notices, PhilipNienhuis, 2020/01/04
- Re: Maintaining copyright notices, John W. Eaton, 2020/01/07
- Re: Maintaining Copyright notices,
Rik <=