Re: [codec] Last Call: <draft-ietf-codec-oggopus-10.txt> (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard
Adam Roach <adam@nostrum.com> Wed, 03 February 2016 22:59 UTC
Return-Path: <adam@nostrum.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A401B3627; Wed, 3 Feb 2016 14:59:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxYGjqqsuAMz; Wed, 3 Feb 2016 14:59:38 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2A71B3626; Wed, 3 Feb 2016 14:59:37 -0800 (PST)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u13MxaWH069679 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 3 Feb 2016 16:59:36 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
Subject: Re: [codec] Last Call: <draft-ietf-codec-oggopus-10.txt> (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard
To: "Timothy B. Terriberry" <tterribe@xiph.org>, Stephan Wenger <stewe@stewe.org>, Ron <ron@debian.org>
References: <20160113141506.11959.44750.idtracker@ietfa.amsl.com> <56A92C39.7060206@nostrum.com> <20160129031044.GB3153@hex.shelbyville.oz> <56B116DA.9010507@nostrum.com> <56B12D2A.4020906@xiph.org> <7A78CD5F-918E-42BF-9090-96C4E4B9DE87@stewe.org> <20160203033855.GO3153@hex.shelbyville.oz> <56B17FC4.7000901@xiph.org> <9B1A525A-5ADE-4AB1-962C-DD826D86C5DA@stewe.org> <56B252D6.9050202@xiph.org>
From: Adam Roach <adam@nostrum.com>
Message-ID: <56B28657.3050801@nostrum.com>
Date: Wed, 03 Feb 2016 16:59:35 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56B252D6.9050202@xiph.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/q4Asbn-g7y25a8ef8IMXDLYyhFQ>
Cc: "codec-chairs@ietf.org" <codec-chairs@ietf.org>, "codec@ietf.org" <codec@ietf.org>, "draft-ietf-codec-oggopus@ietf.org" <draft-ietf-codec-oggopus@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Feb 2016 22:59:41 -0000
From what I can see, the text in RFC 5378 is pretty unambiguous that the rights granted to the IETF trust are non-exclusive. I don't imagine we're arguing about whether authors have the legal ability to grant rights in their work to others under different terms, as long as those terms don't somehow interfere with the rights granted to the IETF. For this document, it's clear that the authors intend to grant additional rights to their text. I think there are two questions here: the first is whether the authors are allowed to be transparent and include the extra rights grant as part of the IETF document, or if they simply indicate that rights grant in some other venue and leave the RFC silent on the topic. I suspect that more information is better than less, and that is not in the IETF's interest to bury the intention to grant additional rights. To that end, I see the RFC 5215 and RFC 6716 approaches as vastly superior to hiding the grant in the XML source [1] or precluding mention altogether. The second question is whether the authors should have the IETF Trust grant these additional rights (in the style of RFC 6716), or whether the authors grant these rights directly (as in RFC 5215). I don't think it matters, but we should certainly allow at least one of the two formulations. It would also be nice if we settled on a recommended practice, and documented it somewhere so that it didn't cause a hullabaloo whenever authors tried to grant additional rights. /a _____ [1] Obligatory Douglas Adams reference: Prosser: But Mr. Dent, the plans have been available in the local planning office for the last nine months. Arthur: Oh yes, well as soon as I heard I went straight round to see them, yesterday afternoon. You hadn't exactly gone out of your way to call attention to them had you? I mean like actually telling anybody or anything. Prosser: But the plans were on display... Arthur: On display? I eventually had to go down to the cellar to find them. Prosser: That's the display department. Arthur: With a torch. Prosser: The lights had probably gone out. Arthur: So had the stairs. Prosser: But look, you found the notice, didn't you? Arthur: Yes. Yes I did. It was on display at the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "beware of the leopard." On 2/3/16 13:19, Timothy B. Terriberry wrote: > Hi Stephan, > > Stephan Wenger wrote: >> However, it is still a procedural end-run around the currently > > in-force IETF position that the IETF reserves the right for itself to > > create derivative works from the RFCs it created (my paraphrasing). > > I am trying to follow the procedure. RFC 5377 says that authors should > be able to grant these rights. The first example I know of people > doing this was by putting a copyright statement in the XML source (RFC > 2629). But my understanding was that it was later preferred that an > additional grant be added in a section of the draft (see RFC 5215 > Section 11). Then with RFC 6716 the IETF decided it was better to add > this grant to the boilerplate text. Now there are objections to that > approach, and we've come full circle to a copyright statement in the > XML source again. As long as there is some way to do it, then I am happy. > >> Now, such a narrow exception does not solve the open source related >> problems, but for that you should really start a debate about the >> copyright policy as a whole, because it would be a major change >> affecting key tradeoffs of that policy that were deliberated literally >> for years. > > I am actually personally fine if most authors do not want to grant > these rights. To my mind, they are the ones who wrote the documents, > and if they see these restrictions as beneficial, it's not my place to > tell them they are not allowed to have them. >
- Re: Last Call: <draft-ietf-codec-oggopus-10.txt> … Robert Sparks
- Re: Last Call: <draft-ietf-codec-oggopus-10.txt> … Ben Campbell
- Re: Last Call: <draft-ietf-codec-oggopus-10.txt> … Joel M. Halpern
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Joel M. Halpern
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Timothy B. Terriberry
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Joel M. Halpern
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Jean-Marc Valin
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Jean-Marc Valin
- Re: Last Call: <draft-ietf-codec-oggopus-10.txt> … Ron
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Ron
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Ron
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Scott Kitterman
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Ben Campbell
- Re: Last Call: <draft-ietf-codec-oggopus-10.txt> … Robert Sparks
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Timothy B. Terriberry
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Stephan Wenger
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Timothy B. Terriberry
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Stephan Wenger
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Phillip Hallam-Baker
- Re: Last Call: <draft-ietf-codec-oggopus-10.txt> … Ron
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Ron
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Timothy B. Terriberry
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Ron
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Timothy B. Terriberry
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Scott Kitterman
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Ben Campbell
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Stephan Wenger
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Ben Campbell
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Jean-Marc Valin
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Ron
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Jean-Marc Valin
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Stephan Wenger
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Timothy B. Terriberry
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Stephan Wenger
- Re: [codec] Last Call: <draft-ietf-codec-oggopus-… Adam Roach