The main goals of this PR are:

• Clear license and copyright information from the `stack/package-docs` page, since that prototype page is going away.
• Use the license and preambles in https://github.com/lsst/templates as the ultimate sources of truth by dynamically importing their content with the new remote-code-block directive.

As part of implementing this, I've designed the documentation to work for both general cases of standalone DM code and documentation work, and the specific cases of Stack packages:

These are the new pages:

• https://developer.lsst.io/v/DM-14813/legal/licensing-overview.html
• https://developer.lsst.io/v/DM-14813/legal/copyright-overview.html
• https://developer.lsst.io/v/DM-14813/stack/license-and-copyright.html

Looks good, although I have some comments.

Are we really saying that developers can choose whatever license they want for standalone projects? Surely if the code is being funded by LSST then the choice of license must be an LSST decision not a developer decision. I would assume that if you are not using GPLv3 then you must at least talk to your T/CAM. I agree that sometimes Apache or MIT are a more obvious choice but it's not up to the developer completely.

For "Applying a license to a repository" if you aren't using a template (because you are standalone) then are we okay with adding one from the list when you create a repository using GitHub UI? It is a bit odd that GitHub does not list creative commons on that menu.

The "Use your institution's email with Git" directive has not made everyone happy but I'm not sure what we can do about it since I think that is is confusing for a senior UW person to use lsst.org email in commits since lsst.org implies AURA.

We should mention that it is possible to set up per-directory tree emails so that work commits and personal project commits can use different emails via IncludeIf (see https://blog.github.com/2017-05-10-git-2-13-has-been-released/#conditional-configuration).

Typo: Background: "does not current exist".

Thanks Tim Jenness

Within SQuaRE, license assignment has been fairly developer driven. Frossie Economou has told me the only hard requirement from the NSF is that we're using an OSI-compliant license. I'll add a "talk to your manager" line since that seems reasonable.

I'll also add a note on the situation where you're creating a repo and using GitHub's templates and add to our Git docs on conditional email configurations.

...has told me the only hard requirement from the NSF is that we're using an OSI-compliant license...

We should be driven by hard requirements from the DM PM in this case! Mind you, I don't object to the form of words you've adopted here.

It looks like this material has just gone live, and marks a substantial change over our previous practices (it may be a reformulation of https://developer.lsst.io/stack/package-docs.html, but that page was explicitly marked as not normative). It seems to me like this merits a post on CLO explaining what changed would be useful.

I agree that this warrants a community post. It's not new policy since I implemented RFC-45 via DM-5383 in February, but without realising that I was doing it on a page that explicitly indicates that we should be using the instructions on confluence. I hadn't noticed that we still have confluence pages referenced from the dev guide. I should have done a community post back then (and I'm surprised I didn't; I was convinced I had but I can't find one).

Sure, I'll write up a post. I was going to pack it in with an announcement of the new documentation system docs i DM-14852, but in reflection it does seem that there's enough here for an announcement.

Thanks Jonathan Sick.