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

 


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

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


Subject: Re: [camp] YAML 1.1



Anish- Yes, you are quite correct -- either I didn't mean contribute in the OASIS sense or I don't know exactly what that means or both. In any case I will let the YAML authors know that the problem is resolved and that permanent archives are also available at http://xml.coverpages.org/yaml.txt .

Robin-  +1 thanks

Best
Alex


On 07/11/2013 00:22, Anish Karmarkar wrote:
On 11/6/13 4:10 PM, Alex Heneveld wrote:

Feedback from Ingy dot Net (one of the authors) is that he expected
they'd be happy for OASIS to host a copy, and he'd canvas the 2 other
co-authors.  But I haven't heard from them, nor had the chance to chase
them.

Don't think we need permission anyway, for any of us to contribute a
copy of it to OASIS, as its license permits copying.


I think we do need permission if it is to be considered a contribution.
The copyright permits copying/hosting of the spec, but is mute on other IPR implications (eg patents, derivative works). For a TC member to make a contribution requires that the TC member ascertain that they have the appropriate rights. I suspect you didn't mean to say "contribution" the way it is used in OASIS that allows the TC to incorporate it in a spec or make derivative works.

But more importantly OASIS (via coverpages.org) has already hosted the spec, so I think it would be sufficient for us to use the coverpages.org URL in our reference.

-Anish
--

(FWIW the three yaml co-authors each own one of yaml.{org,com,net} plus
copies on github and other archives so I don't think they are personally
concerned about it being lost.)

Best
Alex


On 06/11/2013 23:54, Anish Karmarkar wrote:
Sounds like Robin has already solved our problem!
:-)

-Anish
--

On 11/6/13 3:28 PM, Robin Cover wrote:
Seems to me that all of the options will work, in terms of providing
stable resources.  As further backup, the archives copies as cited
below may be useful.  Authors sometimes write me to say "Thanks
for archiving my paper on the Cover Pages: it's the only surviving
copy I could find on the Internet!"   ;-)

http://xml.coverpages.org/yaml.txt
http://xml.coverpages.org/yaml-spec-v1.0-archive-copy.html
http://xml.coverpages.org/yaml-spec-v1.1-archive-copy.html
http://xml.coverpages.org/yaml-spec-v1.2-archive-copy.html

Cheers,

- Robin

On Wed, Nov 6, 2013 at 4:37 PM, Adrian Otto <adrian.otto@rackspace.com
<mailto:adrian.otto@rackspace.com>> wrote:

    Jamie,

    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.

    Adrian

On Nov 7, 2013, at 5:58 AM, Jamie Clark <jamie.clark@oasis-open.org
    <mailto:jamie.clark@oasis-open.org>> wrote:

    Dear colleagues:

    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 */yaml.org
    <http://yaml.org/>/*:

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 <http://xml.org/> or /**xml.coverpages.org
    <http://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.

    Cordially, Jamie

    James Bryce Clark, General Counsel
    OASIS: Advancing open standards for the information society
    http://www.oasis-open.org/who/staff.php#clark

    www.identi.ca/JamieXML <http://www.identi.ca/JamieXML>
    www.twitter.com/JamieXML <http://www.twitter.com/JamieXML>
    http://t.sina.cn/jamiexml
    http://www.slideshare.net/jamiexml
    http://facebook.com/oasis.open





--
Robin Cover
OASIS, Director of Information Services
Editor, Cover Pages and XML Daily Newslink
Email: robin@oasis-open.org <mailto: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 from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




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