Dual/multiple repos and cross-contribution [Motion for Open Repository f

Subject: 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, <duncan@sfractal.com> 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 <athomson@lookingglasscyber.com>
Date: Thu, May 24, 2018 10:32 am
To: Robin Cover <robin@oasis-open.org>
Cc: John-Mark Gurney <jmg@newcontext.com>, "Back, Greg"
<gback@mitre.org>, Bret Jordan <Bret_Jordan@symantec.com>, OASIS CTI TC
list <cti@lists.oasis-open.org>, Interoperability Subcommittee
<cti-interoperability@lists.oasis-open.org>

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

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

--
Robin Cover
OASIS, Director of Information Services
Editor, Cover Pages and XML Daily Newslink
Email: robin@oasis-open.org
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: cti-publicmirror-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: cti-publicmirror-help@lists.oasis-open.org

Robin Cover
OASIS, Director of Information Services
Editor, Cover Pages and XML Daily Newslink
Email: robin@oasis-open.org
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

cti-interoperability message