Dual/multiple repos and cross-contribution [Motion for Open Repository for CTI Interop Issue Tracking

Duncan,

Very narrowly, just on this question

> 

Would it be possible to have both?

From the OASIS Staff (policy) point of view: yes, it's possible, and

a couple groups are (effectively) doing this, though not in so many

words.  TCs can request as any public GitHub repositories as

they want, of both types.

My summary, possibly subject to correction/clarification

For "Open Source" repos and "TC Repos":

The different opportunities and requirements for participation are actually

substantial, even if, in today's world, few of the technical solutions

created under our open source licensing OR under OASIS common

IPR Modes (e.g., Non-Assert) involve patented or patentable

technology that's declared or otherwise impactful -- arguably,

and with some exceptions and caveats.

I'm copying out a few of the FAQs that were written for OASIS

TC Open Repositories about getting content "from" a repo

of Type-A into a repo of Type-B.   Content that's developed in

one is not automatically candidate for the other (no solution

for auto-sync), but when participants/members think the

licensing of one is commensurable with the licensing of the

other, content can be (to use one phrase) "
cross-contributed"

- Robin

FAQs

16. What is the relationship between a TC's Open Repositories and

    its formal specifications?

17. Can a contributor to a TC's Open Repository push a contribution

    to the TC for use in its formal specifications?

18. Can a TC member pull material from one of its TC

    Open Repositories into the TC's formal specifications?

19. If a TC has material such as code snippets in its formal

    specification, may it also place that material in an associated 

    related TC Open Repository?

https://www.oasis-open.org/resources/open-repositories/faq#relationToSpecifications

https://www.oasis-open.org/resources/open-repositories/faq#pushingContentToTC

https://www.oasis-open.org/resources/open-repositories/faq#pullingContentFromRepo

https://www.oasis-open.org/resources/open-repositories/faq#shareableCodeComponents

On Thu, May 24, 2018 at 2:01 PM,  <> wrote:
> "we do *not* have unanimous consent for opening ‘a’ repo"

Is it safe to say that there is no objection in principle to the

concepts of having repo, but the issue is which type (github//oasis-open

vs github//oasis-tcs)?

I've been wrestling with a similar issue in OpenC2 with a similar "can't

win" (ie either non-OASIS can't play; or certain OASIS-members can't

play). If we have to break the tie, I would tend towards favoring OASIS

members (ie the github//oasis-tcs solution). Would it be possible to

have both? I think there would be two ways to do this.

Method A:

github//oasis-tcs is the 'main' repo and the 'definitive' repo

github//oasis-open is 'supplemental'

In this scenario, members would contribute to github//oasis-tcs and

non-members would contribute to github//oasis-open. Note both are

world-readable (so both are open wrt readable). Any member so inclined

could copy github//oasis-open info to their own fork and then contribute

it to github//oasis-tcs. I recognize some legal teams might not approve

their employees doing such but I'm assuming since they have the same

opensource licenses and the same contributor agreements that someone

might be able to do it (only takes one). If no one does it then you have

to look in two places which might not be that big a deal if directory

structures and cross links are put in between the two (ie if you go into

the 'non-OASIS-member' subdir it just is a hotlink to the other repo

(and vice versa).

Method B:

same methodology but reverse which one is 'main/definitive'.

I'd favor A over B and I'd really prefer there was just one - but not

obvious to me how "one" can be made to work for everyone.

Duncan Sparrell

sFractal Consulting LLC

iPhone, iTypo, iApologize

-------- Original Message --------

Subject: [cti] Re: [cti-interoperability] Re: [cti] Re: [EXT]

[cti-interoperability] Motion for Open Repository for CTI Interop Issue

Tracking

From: Allan Thomson <>

Date: Thu, May 24, 2018 10:32 am

To: Robin Cover <>

Cc: John-Mark Gurney <>, "Back, Greg"

<>, Bret Jordan <>, OASIS CTI TC

list <>, Interoperability Subcommittee

<>

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

 Date: Thursday, May 24, 2018 at 7:02 AM

 To: Allan Thomson <>

 Cc: John-Mark Gurney <>, "Back, Greg"

<>, Bret Jordan <>,

"" <>, Interoperability

Subcommittee <>

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

- Robin

[1] OASIS TC Open (Source) Repositories versus Repositories for TC

Members' Chartered Work

https://tinyurl.com/ydyjd3xz

[2] "code" versys not-code (one example)

Code Components which may be found in IETF Contributions and IETF

Documents

http://trustee.ietf.org/license-info/Code-Components-List-4-23-09.txt

IESG Statement on Copyright

https://www.ietf.org/iesg/statement/copyright.html

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)

https://lists.oasis-open.org/archives/cti/201805/msg00041.html

https://lists.oasis-open.org/archives/cti/201805/msg00042.html

https://lists.oasis-open.org/archives/cti/201805/msg00049.html

https://lists.oasis-open.org/archives/cti/201805/msg00050.html

https://lists.oasis-open.org/archives/cti/201805/msg00051.html

https://lists.oasis-open.org/archives/cti/201805/msg00052.html

https://lists.oasis-open.org/archives/cti/201805/msg00053.html

https://lists.oasis-open.org/archives/cti/201805/msg00054.html\https://lists.oasis-open.org/archives/cti/201805/msg00055.html

https://lists.oasis-open.org/archives/cti-interoperability/201805/msg00005.html

https://lists.oasis-open.org/archives/cti-interoperability/201805/msg00006.html

https://lists.oasis-open.org/archives/cti-interoperability/201805/msg00007.html

https://lists.oasis-open.org/archives/cti-interoperability/201805/msg00008.html

https://lists.oasis-open.org/archives/cti-interoperability/201805/msg00009.html

https://lists.oasis-open.org/archives/cti-interoperability/201805/msg00010.html

https://lists.oasis-open.org/archives/cti-interoperability/201805/msg00011.html

https://lists.oasis-open.org/archives/cti-interoperability/201805/msg00012.html

  On Wed, May 23, 2018 at 7:21 PM, Allan Thomson

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

"<mailto:> on behalf of

Bret Jordan" <<mailto:>

on behalf of <mailto:>>

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: 

<> on behalf of Allan Thomson

<>

     > 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

-- 

  Robin Cover

 OASIS, Director of Information Services

 Editor, Cover Pages and XML Daily Newslink

 Email: 

 Staff bio:  http://www.oasis-open.org/people/staff/robin-cover

 Cover Pages: http://xml.coverpages.org/

 Newsletter:  http://xml.coverpages.org/newsletterArchive.html

 Tel: +1 972-296-1783

---------------------------------------------------------------------

To unsubscribe, e-mail: 

For additional commands, e-mail: 

-- 

Robin Cover
OASIS, Director of Information Services
Editor, Cover Pages and XML Daily Newslink
Email: 
Staff bio: http://www.oasis-open.org/people/staff/robin-cover
Cover Pages: http://xml.coverpages.org/
Newsletter: http://xml.coverpages.org/newsletterArchive.html
Tel: +1 972-296-1783