Thanks so much for helping us address this concern. I really like part of option 3, which would be for YAML's authors to post the spec to github. That requires minimal participation from them, and solves the reference stability problem. It is also much
cleaner than a rights transfer.
We understand that the TC is interested in invoking an externally-developed markup language (or similar methodology) called YAML, as part of an OASIS specification. However, the TC wishes to ensure that a stable copy can be properly provided and "secured"
at a known URL ... so that your TC's work product does not point to a URL space that might become empty in the future.
As a "normative reference" used within the CAMP specs, its IPR issues and similar considerations for the OASIS spec are well documented in our rules, and as we have been advised, are understood by your committee. YAML may have no clear terms or licensing;
but generally speaking, the TC is free to elect to reference it normatively, as its technical decision, just as it might other non-standards-track and perhaps-unlicensed works like RFC 4627.
However, this spec currently resides at http://yaml.org/spec/1.1/, which unlike IETF RFCs, is a private website of unknown provenance and some age.
OASIS as a standards host and publisher can only publish, display and re-use material that some party assures us, under our rules, that we have sufficient rights to re-post and use.
* Our IPR Policy assures us that we get those rights, for CONTRIBUTIONS from a member. But as you know, that member must ascertain for itself that it has the right to make that contribution to the TC, and then make it.
* Our policies also permit members or nonmembers to make explicit contributions into a TC via our PUBLIC COMMENT facility; but here too, the commenter takes upon itself the responsibility for the permissions needed to do so. For example, open source
material can be taken in, this way, by a member or commenter who does so -- in reliance on a sufficient ASF Apache license, nonassertion covenant or similar general unconditional permission.
Other than by those two methods, OASIS TCs cannot re-publish the work of other entities. One reason is that its inclusion in the TC's document repository, generally, would be misleading -- putting it there is the equivalent of claiming that the OASIS
TC has the usual OASIS rights to re-publish, re-use and derive from it.
We suggest that your TC or its members may have four options to up-grading the stability of the cite for
1. Seek YAML's authors' permission to contribute it into your TC, thus giving it a longer archival life, among other things.
2. Seek YAML's authors' permission to make it its own TC, with mostly the same outcome, except that this would make it more *generally* available, not just to CAMP.
3. Encourage them to re-post it to some other more archivally-predictable source, like GitHub or, if our communications staff can identify a proper case for it, the auxiliary sites we manage outside of the scope of our IPR policy, such as
xml.org or xml.coverpages.org
. I have copied Carol Geyer and Robin Cover here, to see whether such a solution might be available.
4. Review the rights available in the YAML work (which may include additional declarations or reservations not known to me) and conclude that an OASIS member holds, or can acquire, the rights itself to do #1, #2 or #3.
Please let us know if we can assist with any of these approaches; as informally discussed, we're happy to chat with the YAML folks if that would be useful.