RE: [cti] Status of CTI OASIS Open Repositories

["Back, Greg" <gback@mitre.org>]

[Consolidating responses to all three messages here]

Leaving this issue of TC Work Product repos aside, "OASIS Open Repositories" (perhaps unfortunately named due to the confusion with the oasis-open.org domain that OASIS uses for its entire web presence), are defined in [1] and require a signed CLA [2]. You don't need to be an OASIS member to contribute to the open repositories.

I think it is unwise to create an organization on GitHub that accepts contributions without (at least implicitly) requiring contributors to agree to terms similar to the OASIS CLA. If you believe that simply having text that says "by submitting an issue or pull request, you agree that... " is preferred to "formally" signing the OASIS CLA, I think that's a valid issue for the TC to discuss. 

I find it unlikely that any organization will permit contributions to the organization (which is what I assume you mean by "project") you propose, that would not also permit contributions to the "oasis-open" organization for Open Repository. I'm not an IP lawyer, that's why I defer to what OASIS has established.

Greg

[1] https://www.oasis-open.org/resources/open-repositories/
[2] https://www.oasis-open.org/resources/open-repositories/cla/individual-cla

[UNRELATED TO THE ABOVE] For the record, I personally disagree with the decision to not make the schemas authoritative, but recognize that decision has already been made.


> -----Original Message-----
> From: Bret Jordan (CS) [mailto:Bret_Jordan@symantec.com]
> Sent: Tuesday, October 11, 2016 12:14 PM
> To: Back, Greg <gback@mitre.org>; Trey Darley <trey@kingfisherops.com>
> Cc: cti@lists.oasis-open.org
> Subject: Re: [cti] Status of CTI OASIS Open Repositories
> 
> We have two fundamentally different needs...
> 
> 
> 
> 
> 1) A place to keep and track issues against the published specifications.  We
> are wanting to use the Github issue tracker for this instead of using JIRA.  This
> is totally independent from the work you are doing Greg.
> 
> 
> 
> 
> 2) We need a place for opensource projects that are designed to increase
> adoption of STIX and TAXII to live.  JSON schemas will go here as well because
> of weird rules in OASIS land with schemas.  Namely, if you produce a schema
> for an OASIS standard, the schema becomes authoritative and normative.
> We want the specifications to be authoritative and the schemas to be just
> helps.
> 
> 
> 
> 
> Bret
> 
> ________________________________
> 
> From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> on behalf of Back,
> Greg <gback@mitre.org>
> Sent: Tuesday, October 11, 2016 7:40:05 AM
> To: Trey Darley
> Cc: cti@lists.oasis-open.org
> Subject: RE: [cti] Status of CTI OASIS Open Repositories
> 
> Thanks for the feedback, Trey.
> 
> > I *thought* we were talking about #2.
> 
> Bret seems to be talking about #1, which is why I was confused.
> 
> > The biggest advantage I see is the
> > ability to deal with issues and pull requests from non-TC members on
> > open source projects initiated up by TC members.
> 
> This is possible in OASIS open repositories today. The CLA that open
> repositories require is similar to that required by other prominent open
> source projects.
> 
> > If we're going down the road of hosting things like the STIX 1=>2
> > upgrade utility and the STIX Patterning reference implementation,
> > eventually (I
> > suppose) the next generation of python-stix and libtaxii, then the
> > entire ecosystem (including the TC membership) stands to gain by
> > making it straightforward for non-TC members to contribute bug fixes
> > and feature enhancements to these open source tools.
> 
> Concur. In what way is this not addressed by the current Open Repositories?
> 
> > I am *not* including things like JSON schemata and STIX/TAXII issue
> > tracking in this category. I fully support the stuff that really falls
> > under the rubric of the standards being subject to the normal IPR rules.
> 
> I've heard a consensus desire to keep JSON schemas out of work products,
> and consider them non-normative. If that has changed, we need to re-
> evaluate having the https://github.com/oasis-open/cti-stix2-json-schemas
> repo.
> 
> > > Specifically regarding #2, the strongest argument I've heard is that
> > > it would help keep the CTI open source repos separate from other
> > > TC's, even though this can easily be done by searching for "cti-"
> > > [1]. From a user standpoint, nearly all interaction with GitHub is
> > > done on a per-repository basis, not per-organization. You can't
> > > watch, star, or fork an organization, nor I have I seen any way to
> > > automatically follow new repos that get created in an organization.
> > > The only exception is the "dashboard" view
> > > (https://github.com/orgs/<ORGNAME>/dashboard), which is only
> > > available to members of the organization. For Open Repositories,
> > > under current policies only the maintainers become members of the
> > > organization. I personally never use the dashboard view for any
> > > organizations I am a member of. The result is that each repository
> > > would need to be handled individually, regardless of whether it's in
> > > the same organization as repositories sponsored by other TCs.
> > >
> >
> > That's your experience, Greg. Mine differs.
> >
> > While I do often interact directly with a single Git repository, I
> > also frequently look at the parent Github org for new and interesting
> > projects or when I forget the name of a specific project.
> 
> Fair point. I do this as well. Granted, I spend enough time browsing GitHub
> that I don't mind non-CTI projects in the same organization at CTI projects
> (I've found a lot of interesting projects by just browsing random
> organizations), so my experience may be atypical.
> 
> > Interested to hear what others have to say.
> 
> Agreed
> 
> > > On the other hand, in my experience maintaining multiple
> > > organizations is significantly more work than maintaining multiple
> > > teams within the same organization. Since I imagine OASIS staff will
> > > be maintaining these organizations, I'd like to make it as easy on them as
> possible.
> > >
> >
> > If OASIS sets up a TC-specific Github organization for supporting open
> > source tools and libraries, they can delegate the day-to-day
> > maintenance of that to trusted members of the CTI TC, given that we
> > establish a clear line as to what falls under the rubric of the
> > standards (e.g., JSON schemata and the like) and is subject to the
> > normal IPR rules. In this case, there would be no additional workload on
> OASIS staff.
> >
> > In case we do proceed with option #2, if that is in fact an option,
> > then we should put it to a TC-wide vote and in establishing this CTI
> > Github organization all agree that projects hosted there be subject to
> > licenses amenable to both open source and commercial usage, such as
> > the Apache
> > 2.0 or MIT licenses.
> 
> This is exactly what exists today with open repos (day-to-day maintenance
> trusted to TC members, with licenses amenable to open source and
> commercial usage). I don't see a scenario where administrative rights for
> such an organization would be granted to non-OASIS staff (if so, then a lot of
> my arguments are moot).
> 
> Greg