Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-14813

Move LICENSE/COPYRIGHT docs out of "package docs" documentation

    XMLWordPrintable

Details

    Description

      In the Developer Guide, documentation for LICENSE and COPYRIGHT were originally documented in https://developer.lsst.io/stack/package-docs.html. That page will be rewritten to document the new documentation system for packages and pipelines.lsst.io.

      This ticket is to move the LICENSE and COPYRIGHT discussion out of that page before it is rewritten, and to also add additional context around copyright management in DM.

      Attachments

        Issue Links

          Activity

            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:

            jsick Jonathan Sick added a comment - 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
            tjenness Tim Jenness added a comment -

            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".

            tjenness Tim Jenness added a comment - 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 tjenness

            Within SQuaRE, license assignment has been fairly developer driven. frossie 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.

            jsick Jonathan Sick added a comment - Thanks tjenness Within SQuaRE, license assignment has been fairly developer driven. frossie 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.

            swinbank John Swinbank added a comment - ...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.
            tjenness Tim Jenness added a comment -

            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).

            tjenness Tim Jenness added a comment - 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.

            jsick Jonathan Sick added a comment - 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 jsick.

            swinbank John Swinbank added a comment - Thanks jsick .

            People

              jsick Jonathan Sick
              jsick Jonathan Sick
              Tim Jenness
              John Swinbank, Jonathan Sick, Tim Jenness
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Jenkins

                  No builds found.