Details
-
Type:
RFC
-
Status: Implemented
-
Resolution: Done
-
Component/s: DM
-
Labels:None
-
Location:Reply to this ticket
Description
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
https://www.softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
Summary:
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.
Attachments
Issue Links
- is triggering
-
- Done
-
- Done
-
- Invalid
-
DM-5383 Update developer docs with Copyright instructions
- Done
-
- Done
- relates to
-
- Done
-
- Done
-
- Done
-
- To Do
-
- Done
-
- Done
-
- Withdrawn
Activity
| Field | Original Value | New Value |
|---|---|---|
| Watchers | Frossie Economou, Tim Jenness [ Frossie Economou, Tim Jenness ] | Frossie Economou, Jeff Kantor, Tim Jenness [ Frossie Economou, Jeff Kantor, Tim Jenness ] |
| Resolution | Done [ 10000 ] | |
| Status | Proposed [ 10805 ] | Adopted [ 10806 ] |
| Watchers | Frossie Economou, Jeff Kantor, Jim Bosch, John Swinbank, Jonathan Sick, Kian-Tat Lim, Robert Lupton, Russell Owen, Tim Jenness, Xiuqin Wu [ Frossie Economou, Jeff Kantor, Jim Bosch, John Swinbank, Jonathan Sick, Kian-Tat Lim, Robert Lupton, Russell Owen, Tim Jenness, Xiuqin Wu ] | Frossie Economou, Jeff Kantor, Jim Bosch, John Swinbank, Jonathan Sick, Kian-Tat Lim, Robert Lupton, Russell Owen, Tim Jenness, Wil O'Mullane, Xiuqin Wu [ Frossie Economou, Jeff Kantor, Jim Bosch, John Swinbank, Jonathan Sick, Kian-Tat Lim, Robert Lupton, Russell Owen, Tim Jenness, Wil O'Mullane, Xiuqin Wu ] |
| Comment |
[ Just a few notes since I've dealt with this issue at SLAC:
Foreword: The following is general SLAC policy and not necessarily applicable to the SLAC+AURA MoU (or whatever it is), also IANAL IANAL IANAL: SLAC is fine with modified BSD (as is, obviously LBNL we just took their license wholesale). It's probably fine with Apache. It's generally not okay with GPL though the GPL stuff was negotiated a long time ago so it's fine. So moving to BSD/Apache is fine for us at SLAC. SLAC's contract with the government is actually a bit strict on this, but the reason why GPL generally isn't okay is that any other branch of the US Government (cough, defense, cough) must have ability to modify source code and redistribute without violating the license terms. In some cases, SLAC code *might* fall under reporting to ESTSC, but that's not a big deal and doesn't really apply to us. In general, SLAC people are able to contribute to GPL projects, but SLAC projects shouldn't be GPL. It's a fuzzy line, we could get our Tech Transfer guy to help out if necessary. DESC is moving towards modified BSD, after SLAC's lead primarily, since most people are SLAC people. In general, it's fine to link against GPL code and release your code so long as your code is GPL compatible (Apache V2, MIT, Modified BSD). What you can't do is distribute the LSST Stack as a blob with GPL code underneath and keep your code super secret (generally true, except for cases with GPL+Java+Classpath exceptions, etc...) https://www.gnu.org/licenses/gpl-faq.en.html#WhatDoesCompatMean {quote} It means that the other license and the GNU GPL are compatible; you can combine code released under the other license with code released under the GNU GPL in one larger program. {quote} I believe the premise is that, Apache V2/MIT/Modified BSD are so permissive that you can actually distribute them under a giant GPL-ish blob (effectively a dual-license). Modifications to any GPL code must be licensed under GPL though. This also means that our official release are, in fact, GPL releases though internally the code may be something else. Coming back to mysqlclient, for example. SQLAlchemy *may* use mysqlclient underneath but all SQLAlchemy code is MIT. pandas is BSD and uses sqlalchemy and may use mysqlcient. Distributing a library with both sqlalchemy and mysqlclient would require that library to be licensed under GPL but the code inside it could also be any other license. Distributing that library with a different driver (i.e. not mysqlcient) wouldn't necessitate GPL. Choosing not to distribute any driver would be best, let the user decide. Of course, we have eups so that's not an option (but maybe it is?) IMO the patent exclusion only really matters if we are going to actually apply for patents in the algorithms, but it might be nice to be Apache V2 just so institution comes a long and tries to assert a patent on some image algorithm. In any case, all it really means is that end users don't have to worry about an institution coming along and bullying them for using the LSST stack with patent 123. Again, IANAL IANAL IANAL. ] |
| Status | Adopted [ 10806 ] | Implemented [ 11105 ] |