OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti] Status of CTI OASIS Open Repositories


The problems comes in with having to sign a CLA.  That alone makes the cost of entry too high for some people.  This is why I motion that the TC create a project on Github outside of OASIS for all of this.  Then we solve several issues all at once.


Bret 

Sent from my Commodore 64

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

On Oct 11, 2016, at 12:16 PM, Back, Greg <gback@mitre.org> wrote:

[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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]