Given that we have different opinions on whether this should be an open repo vs tc repo we do *not* have unanimous consent for opening ‘a’ repo.
I will hold off submitting any request until we have a clear decision on what kind of repo it needs to be.
Allan
From: "robin@oasis-open.org" <robin@oasis-open.org>
Date: Thursday, May 24, 2018 at 7:02 AM
To: Allan Thomson <athomson@lookingglasscyber.com>
Cc: John-Mark Gurney <jmg@newcontext.com>, "Back, Greg" <gback@mitre.org>, Bret Jordan <Bret_Jordan@symantec.com>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>, Interoperability Subcommittee <cti-interoperability@lists.oasis-open.org>
Subject: Re: [cti-interoperability] Re: [cti] Re: [EXT] [cti-interoperability] Motion for Open Repository for CTI Interop Issue Tracking
On Allan's draft proposal/motion to create a new public GitHub repository [3], I've tracked with comments from the TC members (Bret, John-Mark, Greg, Jason, Jane) and sense that the TC has a good understanding of the trade-offs between
an OAIS TC Open Repository (open source licensing, anyone can contribute) versus a GitHub repository (primarily) for CTI TC members' use. I have written commentary on the key differences [1]
So I reported to Allan Thomson (and Richard Struse) that we will create a public GitHub repo of either type (or more than one new repositry, if warranted), with the claim that "they both can work just fine", given that we configure the
GitHub repos with Issues turned on, etc
A couple additional thoughts to perhaps help lower the stakes
1) We use stock (boilerplate) language in the README and CONTRIBUTING startup files, but in a case like this, we are happy to supplement the text -- with your recommendations -- to make clear for users and potential users what the goals/purposes
are, and whak kinds of contributions are anticipated, and how anyone can "participate" within the expectations. Allan's draft purpose statement ("A CTI-Interoperability issue tracking repository") can be expanded to clarify further..
2) While we use words like "code" and "contribute" and "participate" in our rules and startup files -- sometimes following GitHub's definitions, which are not entirely precise or consistent, we acknowledge that the repository Maintainers
will always need to exercise some judgment about whether and how to use content that is expressed in a GitHub Issue, Pull Request, Comment, Gist, Wiki page (etc) -- since indeed anyone with a GitHub account can create and link to such content. Most content
that everyone recognizes as "code" can be expressed in any of the above-mentioned ways. While some organizations have attempted to support clear binary distinction between "code" and non-code" [2], we don't try, because the definitions are too difficult to
formulate and applications too difficult to enforce. People mean different things by: (repository "Code"), "contributions", "substantive contributions", "code commits", "editorial changes"...
3) I'm happy to discuss (maybe best on a phone call, if needed, and Chet Ensign could join) some other considerations, but would encourage adoption of the hypothesis that either repo type might work OK, with constraints that are common
to all public open source projects, at OASIS and elsewhere, requiring that some kinds of input merit formal declaration of the user's agreement (e.g., in a CLA) and other kinds of "non-substantive, editorial" content changes do not. Every open source project
I have seen faces these same challenges. Viz.,
[1] OASIS TC Open (Source) Repositories versus Repositories for TC Members' Chartered Work
[2] "code" versys not-code (one example)
Code Components which may be found in IETF Contributions and IETF Documents
IESG Statement on Copyright
In addition to the code component types listed, any text found between the markers <CODE BEGINS> and <CODE ENDS> shall be considered a code component. Authors may wish to use these markers as clear delimiters of code components.
[3] "Motion for Open Repository for CTI Interop Issue Tracking" (with duplicates)
On Wed, May 23, 2018 at 7:21 PM, Allan Thomson <athomson@lookingglasscyber.com> wrote:
John-Mark - As I shared with Greg privately and sharing for the group.
STIXPreferred is a certification program intended to be open to non-TC members and TC-members alike.
So although the interop test documents are work products of the TC, they will be used by the non-TC members to certify their products. We want feedback on that program as a whole and using the open repo to track issues is one possibility.
Secondly, test programs and test data used in future interop tests will be available via this repo (hopefully) and again it would be good to have the option of non-TC members contributing updates/fixes to that data the repo holds.
There might be other STIXPreferred content we want to publish and get feedback on via the repo that would suggest an open policy is better.
I said to Greg that on balance I understand the issue around IPR for interop contributions vs non-member contributions to help the certification program prosper. My preference is to keep the repo open as I think the likelihood of IPR being an issue for interoperability
is low (not zero but low). If someone submits content that will likely cause IPR conflicts then I suggest we would deal with that when it happens.
If others think that this will cause a significant problem with IPR conflicts then please speak up.
Allan Thomson
CTO (+1-408-331-6646)
LookingGlass Cyber Solutions <http://www.lookingglasscyber.com/>
On 5/23/18, 5:05 PM, "John-Mark Gurney" <jmg@newcontext.com> wrote:
Back, Greg wrote this message on Wed, May 23, 2018 at 21:58 +0000:
> I’m fine with either, but I’ll point out that a motion to create an open repo is very different from a motion to create a TC repo. Based on what Allan is saying in the purpose statement, it’s probably more suitable as a TC repo [1], using this form [2].
Again, I would be in support of either one, though.
If there is no code in the repo, then I'm fine w/ an Open repo.
If there will be "code" (i.e. contents in git), then I will agree w/
this should be a TC repo instead. Due to how our business agreements
are structured, I cannot contribute "code" to an open repo. I do read
this as I'm fine contributing to issues of an open repo.
Isn't there a document that people who provide feed back via the
public comment period have to sign when submitting responses?
Sounds like that could help in this situation.
> On 2018-05-22, 20:07, "cti@lists.oasis-open.org<mailto:cti@lists.oasis-open.org> on behalf of Bret Jordan" <cti@lists.oasis-open.org<mailto:cti@lists.oasis-open.org>
on behalf of Bret_Jordan@symantec.com<mailto:Bret_Jordan@symantec.com>> wrote:
>
>
> I second this, however, I would suggest the name just be cti-interop this way as an official work product repo, we could use it for other interop related things. Yes, obviously, it will have an issue tracker, but we could do other things with it as well.
>
>
>
> Bret
>
> ________________________________
> From: cti-interoperability@lists.oasis-open.org <cti-interoperability@lists.oasis-open.org> on behalf of Allan Thomson <athomson@lookingglasscyber.com>
> Sent: Tuesday, May 22, 2018 4:45:42 PM
> To: OASIS CTI TC list
> Cc: Interoperability Subcommittee
> Subject: [EXT] [cti-interoperability] Motion for Open Repository for CTI Interop Issue Tracking
>
>
> I move that the TC approve by unanimous consent requesting OASIS to set up an OASIS Open Repository named cti-interop-issues using the following pieces of information:
>
>
>
> * Purpose Statement: A CTI-Interoperability issue tracking repository
>
> * Initial Maintainers: Allan Thomson, Jason Keirstead
>
> * Open Source License: BSD-3-Clause License
>
> * GitHub Name: cti-interop-issues
>
> * Short Description: OASIS Open Repository: CTI-Interop Issue Tracking
>
>
>
> If there have been no objections by Friday, 25th May, 8am PST, I will submit the form [1] to request OASIS staff to create the repository.
>
>
>
> [1]:
https://clicktime.symantec.com/a/1/O_ihu1E08Xl2-dCkw-ASiK6V6aRPMzaHPgA8JWCVguA=?d=uExWX7fZn2Kl6plF49kKe_LZP8lrMkLtXgjcy41DR0Fu0FSDcexzZAqC2nn1IMYh1vZ5FISBNpMlibp8Q0YGdjpkIAvhfVRjM1dsDF7cV4gT9qa8h0OjnyVkwC9MH38YSKD2lIHqyY8rhnZXjDuzWpBtp-VTHGRkjFV0W281F9vYddlnNEAE25ie-1Nhr0af-1LmnMK3x4VacBd2yc3UUhapIM5Pqqb-yRWtSq1ZVe0EGfmckl5y8-UwGLKOPkChB785CerSuPcODwZCi8FkAo5apC1IyU_dwL9khyfWaWdeH9AkaMHufWKd5VmISpiqqD5sPRcc9KLHxJQ_oIEHIjQQjQRnSPNRM6xRsDeD8nYOLsbdk6iZwtmXnnNOsf4riJlDR8Bh2-ZNEkQF5Kbql5CIO0Bj-vXyUHnKYHCAjWuD7fSaz6YXLfHN71fJx4whN1cAV3AA_F8MAUW8uP9AXd6s3VH576SP6yheifXsvXSPrvmnnX2t1VHrp2KdF36FZzPIqViSYyR4Mk5GEw%3D%3D&u=https%3A%2F%2Fwww.oasis-open.org%2Fresources%2Ftc-admin-requests%2Fopen-repository-request
>
>
>
> Allan
--
John-Mark
--
|