jsr348
  1. jsr348
  2. JSR348-18

1.5.2 - Add GitHub to the list of approved collaboration software

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Component/s: Process Doc
    • Labels:
      None

      Description

      Process Doc Section 1.5.2: "We must ensure that java.net is on the Approved List."

      GitHub is clearly a first-rate collaboration suite, and should be whitelisted.

        Activity

        Hide
        lightguard added a comment -

        +1

        GitHub, CodeHaus, Google Code, Bitbucket, etc.

        Show
        lightguard added a comment - +1 GitHub, CodeHaus, Google Code, Bitbucket, etc.
        Hide
        pcurran added a comment -

        There will be no list of approved collaboration software (you seem to be working from the out-of-date JSR1 list rather than from the actual draft of the Process Document.

        Show
        pcurran added a comment - There will be no list of approved collaboration software (you seem to be working from the out-of-date JSR1 list rather than from the actual draft of the Process Document.
        Hide
        lincolnbaxter added a comment -

        So this section has already been stricken from the document?

        These ideas were drafted by an independent group reviewing the Early Draft from June 21, 2011 - apologies for out-of-date issues.

        Show
        lincolnbaxter added a comment - So this section has already been stricken from the document? These ideas were drafted by an independent group reviewing the Early Draft from June 21, 2011 - apologies for out-of-date issues.
        Hide
        starksm64 added a comment -

        The June 22 minutes (http://java.net/downloads/jsr348/Meeting%20Materials/2011-06-22-Minutes.html) include this summary:

        Terms of Use for Collaboration software

        Patrick reported that he had a brief (impromptu) discussion on this issue internally, and that the conclusion was that it would not be appropriate for a legal team to "approve" the Terms of Use for any collaboration software that they had no control over (this could be a legal liablility.) Even if we were to try to do so, Terms of Use can change at any time, making it effectively impossible. Instead, we'll probably need to take a "Caveat Emptor" approach, reminding Spec Leads that they have legal obligations under the JSPA that could be compromised if they accept contributions from people who have not signed the JSPA or some other Contributor Agreement. Each Spec Lead already must manage this risk, and should continue to do so.

        Patrick explained the direction (write up later.)

        John suggested that if this is the direction we propose to take then the Spec Lead should assert in the JSR submission that they understand the risks and accept responsibility.

        Patrick agreed to draft something very high level for EDR, recognizing that it would need to be refined later after discussion with Legal.

        Show
        starksm64 added a comment - The June 22 minutes ( http://java.net/downloads/jsr348/Meeting%20Materials/2011-06-22-Minutes.html ) include this summary: Terms of Use for Collaboration software Patrick reported that he had a brief (impromptu) discussion on this issue internally, and that the conclusion was that it would not be appropriate for a legal team to "approve" the Terms of Use for any collaboration software that they had no control over (this could be a legal liablility.) Even if we were to try to do so, Terms of Use can change at any time, making it effectively impossible. Instead, we'll probably need to take a "Caveat Emptor" approach, reminding Spec Leads that they have legal obligations under the JSPA that could be compromised if they accept contributions from people who have not signed the JSPA or some other Contributor Agreement. Each Spec Lead already must manage this risk, and should continue to do so. Patrick explained the direction (write up later.) John suggested that if this is the direction we propose to take then the Spec Lead should assert in the JSR submission that they understand the risks and accept responsibility. Patrick agreed to draft something very high level for EDR, recognizing that it would need to be refined later after discussion with Legal.
        Hide
        starksm64 added a comment -

        The June 29 (http://java.net/downloads/jsr348/Meeting%20Materials/2011-06-29-Minutes.html) include this summary:

        Terms of Use for collaboration software

        Patrick reviewed the current draft language - basically a "caveat emptor" to the Spec Lead. It was suggested that we might want to issue some kind of warning notice to people who join discussion aliases that their contributions might not be accepted unless they have signed the JSPA. However, we also agreed that vague language such as this would not provide any kind of legal cover, and might in fact be misleading.

        This will need further discussion - involving legal advice - but is good enough for EDR.

        Show
        starksm64 added a comment - The June 29 ( http://java.net/downloads/jsr348/Meeting%20Materials/2011-06-29-Minutes.html ) include this summary: Terms of Use for collaboration software Patrick reviewed the current draft language - basically a "caveat emptor" to the Spec Lead. It was suggested that we might want to issue some kind of warning notice to people who join discussion aliases that their contributions might not be accepted unless they have signed the JSPA. However, we also agreed that vague language such as this would not provide any kind of legal cover, and might in fact be misleading. This will need further discussion - involving legal advice - but is good enough for EDR.
        Hide
        starksm64 added a comment -

        The current language in the process document (http://java.net/downloads/jsr348/Working%20documents/JCP%20NEXT%202.8-29JUL2011-Clean.pdf) states, lines 167-174:

        will publish this information on the public JSR Page. The Spec Lead must also provide a pointer to any
        Terms of Use required to use the collaboration tools so that the EC and prospective EG members can
        judge whether they are compatible with the JSPA.

        If the EG changes its collaboration tools during the life of the JSR these changes must be reported to
        the PMO, who will update the relevant information on the JSR Page. Any such changes must ensure
        that previously-published information is incorporated into the new tools. When voting to approve a
        JSR's transition to the next stage EC members are expected to take into consideration the extent to
        which the Spec Lead is meeting the transparency requirements

        Show
        starksm64 added a comment - The current language in the process document ( http://java.net/downloads/jsr348/Working%20documents/JCP%20NEXT%202.8-29JUL2011-Clean.pdf ) states, lines 167-174: will publish this information on the public JSR Page. The Spec Lead must also provide a pointer to any Terms of Use required to use the collaboration tools so that the EC and prospective EG members can judge whether they are compatible with the JSPA. If the EG changes its collaboration tools during the life of the JSR these changes must be reported to the PMO, who will update the relevant information on the JSR Page. Any such changes must ensure that previously-published information is incorporated into the new tools. When voting to approve a JSR's transition to the next stage EC members are expected to take into consideration the extent to which the Spec Lead is meeting the transparency requirements
        Hide
        pcurran added a comment -

        Closing this, since I think we've addressed the submitter's concern.

        Show
        pcurran added a comment - Closing this, since I think we've addressed the submitter's concern.
        Hide
        lincolnbaxter added a comment -

        I have to say that this is fantastic! my concerns have been more than addressed.

        Show
        lincolnbaxter added a comment - I have to say that this is fantastic! my concerns have been more than addressed.

          People

          • Assignee:
            Unassigned
            Reporter:
            lincolnbaxter
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: