Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-10.txt

Vincent Roca <vincent.roca@inria.fr> Tue, 22 January 2019 21:43 UTC

Return-Path: <vincent.roca@inria.fr>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2624213110B; Tue, 22 Jan 2019 13:43:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 rqBgCqaUJJUi; Tue, 22 Jan 2019 13:43:39 -0800 (PST)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F80131138; Tue, 22 Jan 2019 13:43:38 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.56,508,1539640800"; d="scan'208,217";a="365319451"
Received: from ral061r.vpn.inria.fr ([128.93.178.61]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jan 2019 22:43:36 +0100
From: Vincent Roca <vincent.roca@inria.fr>
Message-Id: <AC42A254-263C-4773-B5B2-38903F2CCD39@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D72E40D6-7276-4FBA-A188-9CF681A9F4F8"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Tue, 22 Jan 2019 22:43:35 +0100
In-Reply-To: <CAKKJt-f6rHpdynqzOCj729Vfeb83s7KAYSpVXhbUdOkGtZUcMQ@mail.gmail.com>
Cc: Vincent Roca <vincent.roca@inria.fr>, "Black, David" <David.Black@dell.com>, "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>, Emmanuel Baccelli <emmanuel.baccelli@inria.fr>, "tsvwg@ietf.org" <tsvwg@ietf.org>, Belkacem TEIBI <belkacem.teibi@gmail.com>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
References: <154775953855.10322.13019924919889018658@ietfa.amsl.com> <4A1F8C46-9E3A-4F0C-B1CF-E2582100349F@inria.fr> <3BAA052F-FCB2-43CB-8F09-996EB76C1170@kuehlewind.net> <CE03DB3D7B45C245BCA0D24327794936303F0C7A@MX307CL04.corp.emc.com> <CAKKJt-f6rHpdynqzOCj729Vfeb83s7KAYSpVXhbUdOkGtZUcMQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Q_P__3PY-A5zZuX6En2LLv5I2nA>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-10.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Jan 2019 21:43:44 -0000

Dear Spencer, Mirja, David, all,

Thanks a lot for help. From the official IETF counsel answer (I never saw it before), I see the best option is
to engage discussions with the two TinyMT32 authors.

I’ll do that tomorrow, keeping only Wes in CC (our shepherd) to avoid annoying you all (otherwise tell me).
I’ll let them choose between two options: 

- they authorize us to remove their copyright and licence (since I also understand there’s a slight difference
  in the licence) in the existing I-D;

- or they co-author with us a new I-D that only focusses on the core PRNG that we add as normative reference
  to this I-D. In that case we'll just keep the two mapping functions in the RLC I-D (it’s really specific to RLC and
  masking is **usually a bad practice**).

Cheers,

  Vincent


> Le 21 janv. 2019 à 23:52, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> a écrit :
> 
> Hi, David,
> 
> On Mon, Jan 21, 2019 at 8:44 AM Black, David <David.Black@dell.com <mailto:David.Black@dell.com>> wrote:
> Hi Mirja,
> 
> > There are currently two contradicting copyright statements.
> 
> I respectfully disagree, as use of multiple copyright statements for code is common, particularly when a BSD code license is used.
> 
> However, the IESG clearly needs the view of IETF legal counsel on this topic - when might we expect to see that, and how can I help?
> 
> Thanks, --David
> 
> (snip)
> 
> There's been a certain amount of to/cc trimming and adding on Mirja's discuss thread, by multiple ADs, and maybe by other folk, so I'm not sure who has actually seen this response from the IETF counsel, Brad Biddle. 
> 
> So, at least we are all starting from the same place now?
> 
> Spencer
> 
>  > Am 14.10.2018 um 00:25 schrieb Brad Biddle <brad@biddle.law>:
> > 
> > Alissa and all — I think the inclusion of BSD-licensed code with a third party copyright notice is inconsistent with the literal requirements of BCP 78, as Mirja and Adam suggest in then thread below. Further, I don’t think that the TLP provision or blog post that Adam cites necessarily suggest support in spirit for this approach (I believe each are making different points, described further below). I agree with Adam’s conclusion that there is likely little practical impact here of including BSD licensed code with a copyright notice of a third party instead of the IETF, given that the rights are functionally identical either way. But think there are several reasons to NOT simply proceed with this as our practice, absent an explicit decision to do so and and effort to align our practices and IPR documents accordingly:
> > 
> >       • Of course, we should follow the rules we set for ourselves, and the “additional copyright notices are not permitted” [1] rule is clear. BCP 78 does have an explicit exception process that that doesn’t seem applicable here. I don’t read either TLP Section 4 [2] or the cited blog post [3] as providing or suggesting additional exceptions. The TLP Section 4(c) provision that Adam cites is focused on clarifying that a party that takes a license from IETF under BSD terms is not simultaneously subject to Section 3’s more restrictive terms — i.e. it’s a different question than what we’re discussing here. Likewise, I understand the blog post to be focused on when an IETF copyright notice is required, and not focused on the idea of a third party notice. So: I think we have an unambiguous rule of no third party copyright notices.
> > 
> >       • More substantively, the rights that the IETF gets under our normal BCP 78 terms and the rights we get when licensing in code under BSD terms are not identical. BCP 78 enables essentially unlimited future use by the IETF. BSD licensed code comes with some additional (modest) restrictions, such as the requirement to always provide particular required notices and disclaimers with any reuse. If we take in contributions under different terms, we have to make sure we manage our use to map to those terms. Our normal BCP 78 model avoids this problem: we get all contributions in under identical, broad terms.
> > 
> >       • Here, and I suspect in future cases if we were to make this a practice, it’s not clear that labeling the code with only third party notices is appropriate. In this case I gather that there were some IETF-specific tweaks. Assuming these are reflected in copyrightable elements of the code, it’s inaccurate to only list the original copyright owners and not IETF.
> > 
> > I suggest that we ask the authors of this code to provide to IETF as a normal BCP 78 “Contribution,” and then include the code with an IETF copyright notice. If they don’t want to do so (or can’t for some reason), then I suggest removing the code from the draft.
> > 
> > If there is a desire to include third party BSD code on a ‘license-in = license-out’ basis, I think that’s potentially feasible, but I’d suggest we explicitly change our rules to address this scenario, and consider whether there are are practical implications for how we manage our contributions if we have materials coming in under two different licensing models.
> > 
> > Please let me know if you think I’m missing something. Happy to discuss further, of course.
> > 
> > Thanks,
> > Brad
> > (IETF legal counsel)
> > 
> > Brad Biddle | brad@biddle.law | +1.503.502.1259 (mobile) | http://biddle.law <http://biddle.law/>