Clarification on the state of DM's license and copyright policies

Data Management
#1

I’m writing a new Python package (not associated with the stack) and I’d like to use our current best-practices for declaring copyright and license information. RFC-45 provides some guidance on how to include a copyright statement (tl;dr use a COPYRIGHT file), but I’m unsure about the policy on license declaration. Do I still need to put GPLv3 bloat at the top of each file, or can I also refer to the package’s central LICENSE file?

Ideally I’d love for the top of my files to just include

# See COPYRIGHT and LICENSE files at the top of the source tree.

Update: After talking IRL to @josh it seems that I can just use a set of LICENSE and COPYRIGHT files without bothering to add boilerplate in the source code files. I’m also going to use the MIT license. If anyone has any objections, let me know. And again, this is specific to greenfield projects.

#2

As far as we know, there is no mandate from an external legal perspective to have per-file boilerplate. So I concur with Josh for your “greenfield” project.

For LSST packages, some institutions do require a per-file pointer to the COPYRIGHT file. LSST packages are also by default GPL3, of course.

#3

One complication is that the Free Software Foundation really would like you to note the license itself in each source file and does not want you to just say “see LICENSE file for license”: https://www.gnu.org/licenses/gpl-faq.html#NoticeInSourceFile

The instructions state explicitly that the short form of GPL should be included in every source file.

#4

How did RFC-45 get adopted, then?

#5

Because this is a (strong) suggestion, not a legal requirement.

#6

Re-opening this topic because I’m working on some prototype documentation on how to document LSST science pipeline packages. Part of it touches on the boilerplate (i.e., for GPLv3)

Can I state in the documentation that the full GPLv3 boilerplate is not needed at all for any LSST stack code if a LICENSE and COPYRIGHT file is properly added to the git repo?

#7

As is stated above and confirmed by @ktl, FSF strongly suggest you do include the boiler plate (they are concerned about files being cherry-picked and losing the license information) but legally we are not bound by that suggestion. I’ve always included it but the LSST policy is not for me to say. I’m more concerned by the copyright status of the Subaru patches that have been reintegrated…

1 Like
#8

Okay, the docs will continue to advocate putting the giant GPLv3 legalese on all code files.

If someone wants to take a leap and RFC that we go against the FSF’s advice and drop that legalese, I’d be supportive.

And to @timj’s point, I do think it would be good for the health of this project if we knew who owned exactly what bits of HSC-fork code that’s being merged back. That’s a prerequisite for any straightforward discussion of whether we’d like to relicense the code base in the future to become more consistent with the expectations of the open source scientific community.

For example, here’s a fun fact about GPLv3:

See https://confluence.crbs.ucsd.edu/display/CRBS/Releasing+Open+Source+Software+at+UCSD

#9

Please wait a bit. I’m working on formulating something.

1 Like
#10

My 2 cents. NCSA has its own open source license, which I have used and its very similar to the MIT license. https://opensource.org/licenses/NCSA

#11

Hi all - over in the DESC we are discussing software licensing, and the implications of the LSST GPL3 have come up. As we digest these, can I just ask: is the LSST GPL3 choice here to stay, or are MIT or BSD being considered as an alternative? Thanks!

#12

I am not stating an official DM position here… My understanding is that all copyright holders need to agree for some code to be relicensed. As things stand we are not entirely sure of the copyright situation for the code that is being ported back from the HSC fork. We do think that the contracts with Princeton and UW allow LSST to specify the license.

Additionally, we do rely on some GPL libraries. These would have to be replaced with LGPL/BSD/MIT versions.

I don’t think that the project is averse to a looser license. If it was deemed to be a priority for this to be addressed I don’t imagine any of the issues are insurmountable with sufficient effort. Don’t take this as an official project statement though.

#13

This shouldn’t be an issue: if need be, we can easily find the responsible parties and discuss the situation with them, and, in the worst case, there’s a sufficiently small amount of code in this state that reimplementing it from scratch wouldn’t be an issue.

Note that I’m not taking a position on the policy we should adopt with respect to licensing, merely stating that the HSC fork should not be a significant factor in determining what that policy is.

#14

I think we are agreed. Changing license has to be a top level directive that is deemed to be of sufficient importance that we can iron out all these issues. Without that, inertia will see us staying with GPLv3. I don’t think any of the issues are insurmountable.

#15

Thanks very much! This is most helpful for our planning :slight_smile: