Location:Reply to this ticket
Purpose: Adopt the most lightweight (from the point of maintenance) copyright process for software written in construction that is still compatible with our contractual obligations and open source principles.
Proposal for default practice:
1. Each file has a header that says “See COPYRIGHT file at the top of the source tree”.
2. The COPYRIGHT file is considered a template file, with sections of it replaceable by robots.
3. The copyright file has a line per institution that contributed to the code, in a date range eg.
Copyright University of Waterloo (2012-2015)
4. If people from two institutions are making substantial contributions to that code, they add their institution to the copyright line.
Copyright University of Waterloo and AURA/LSST (2012-2015)
5. Additional boilerplate will be included in the COPYRIGHT file reflecting the AURA/LSST-institution contractual arrangements (specifically perpetual license to AURA/LSST to modify and redistribute)
6. Requirement of developers: Use your institutional email address for commits
7. Requirement on SQuaRE: Insert template into repos. Periodically update the end date of the notice and run a simple check to make sure the list of intitutions is consistent (eg a file has a UW line if all the commits are from people with UW addresses). Scan for non-institutional emails in the commits (eg. people pushing with their gmail address).
8. This is in the default process for "normal" work. If someone is developing code that they are worried is of commercial value or other concerns that require a more defensive process, they are free to engage in more heavyweight processes such as including copyright statements in every file. They would undertake to maintain that non-default process.
Note that the construction contracts do not require copyright assignment to AURA/LSST and we will not require copyright assignment from open source contributors.
#6 is the most significant as VCS information can legally be used to resolve disputed claims.
Background (skip if you’re fine with the above):
- Many conventions on copyright in open source come from FSF guidance for GPL-license source but that has been drawn for specific situations that are not a particular worry to us (e.g. commercial parties subverting open source code).
- Once again we are guided by the Software Freedom Law Center
Copyright is implicit (it does not need to be asserted). A central Copyright file notice is therefore sufficient in cases where it is unlikely that a file can be separated form its source tree. The Version Control system is considered adequate proof of individual contributions.
- is triggering
DM-4220 Convert copyright/license statements to one-liners for RFC-45
DM-7042 validate_base API refinement
DM-3487 Implement RFC-45 Copyright File
DM-5383 Update developer docs with Copyright instructions
DM-5382 Update template repository with new copyright rules
- relates to
DM-5031 Enable external code contributions
DM-13565 Put correct copyright/license headers in all jointcal files
DM-13966 Research why license is not detected for daf_butler
DM-4535 Execute stack copyright/license conversion
- To Do
DM-593 Update all DM Software Copyright and License Agreement notices to reflect AURA/LSST
DM-13599 Update copyright info following RFC-45
RFC-908 GPL (and a lot of other licenses) doesn't require one to include long GPL header in every source file
I can't see a comment on this above, but FSF really do want their boiler plate in each source file and not just a one liner to look in a different file. See https://www.gnu.org/licenses/gpl-howto.html
I think if this RFC ended up with
- Add the GPL copying permission statement
- A reference to a COPYRIGHT file for the copyright information
Then it would seem that we could proceed without having to ask a lawyer. Removing the copying permission statement might be unwise.
BSD is different of course and that leads to a discussion of
Thanks Tim Jenness, I think your comment clarifies an implementation strategy sufficiently that I feel confident enough in being able to take on
DM-5383 and DM-5382. We can move further discussion of implementation details to DM-5383, in particular.
Brian Van Klaveren, this RFC is mainly meant to be discussing how to manage copyright and license in our code, not a discussion over which license we want to be using. The basic ideas of:
- small stub in each source file
- License in one file.
- Copyright in one file, institutional rather than "LSST".
- Use of proper AURA name in AURA copyrights.
- Committing with corporate email address.
are all good practice regardless of the specific license choice.
See this recent GitHub blog post for background on GitHub’s license metadata service: https://github.com/blog/2252-license-now-displayed-on-repository-overview
For a look at my implementation of
RFC-45in a Stack package, see https://github.com/lsst/validate_base/tree/tickets/DM-7692