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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Mon, 21 January 2019 22:52 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
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 5759512D4E7; Mon, 21 Jan 2019 14:52:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.739
X-Spam-Level:
X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 6Tf-blhpy6wV; Mon, 21 Jan 2019 14:52:51 -0800 (PST)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 998D2129BBF; Mon, 21 Jan 2019 14:52:50 -0800 (PST)
Received: by mail-lj1-x234.google.com with SMTP id q2-v6so18897626lji.10; Mon, 21 Jan 2019 14:52:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cEdxKkhgVVSpR6O7wcWvNJTAVbzzBNIxxAzM7GXvTbQ=; b=bbxhReVx2SJIBqsXfswsvADwW+M6lc6nv9psyra9p+PYt2K0EAADBOJ4QPcoOntMzT iBixvO4iZ5VY/QmoMU8UbNBDDckMQMuKZcN566KkVK22hTqukPXUtHtggZ/hKS4/F1rf 8jezgRTBLj2UYZ0UOfevLUYgAS5ALek/RkyA32Wztk1IT43WFOp+ZbXZrKQVJ2ABDrx7 LBtb5YgSJhItIPGP96g0mvg3TLvgqio7X41IZo2jRloNxOwwq5e8mHm0Xzze2opKxpk2 AcIpdR8zizMO0RNCbfvpq/W5uxTnxevhiS/Bi+wP/kkOJkAw5xpv6+Y9H2DaorQMF9nw APgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cEdxKkhgVVSpR6O7wcWvNJTAVbzzBNIxxAzM7GXvTbQ=; b=irXphpGWzpl/53Z8lzi8cCN82h4GtlHbwfF/nAYM7H89vst6uFHK+K848LmMiA/M9F czjvekZSri6gQbNJPO22RygokP6NQfSABnHR0T9kdlTIeJg5GQr3lV7iTgdhlLXxhd4y MD5/XIR19wlXBp3vPydNfEiF20i4hkzbO+SUIjTNF/8dIGyaYXXUUOThEwEIl9nuHwZG 36AvF/9faoOh10w4a6MkXIPaP6rFZ+5SsVBmMGlgLETYGUpufJ3qK0+w8cNqJ7vvboXX 6JPLNAY1yx2r0L/nd5uRvat4IjxnINcWKm5Ax5vRKP2E21ifH0fUDJYzCuQqDYLkFySO zxzg==
X-Gm-Message-State: AJcUukflSVtmjCoaaubi7vlyVUsp3fAQwl+/LF4Kb8pSpsOYfKk+hmos klCBdJ1bdEY6tqRVYEeDIQoofHKxrxtF1T3o7Pc=
X-Google-Smtp-Source: ALg8bN6mr161xBx2phNbFY7MpvMSwVMybMrEynLI/jkQn0V5atrlqDUYpseOWew85Ui4Od8IbEPIU7wW5OmZL0UNJiY=
X-Received: by 2002:a2e:310a:: with SMTP id x10-v6mr20467395ljx.6.1548111168508; Mon, 21 Jan 2019 14:52:48 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <CE03DB3D7B45C245BCA0D24327794936303F0C7A@MX307CL04.corp.emc.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Mon, 21 Jan 2019 16:52:35 -0600
Message-ID: <CAKKJt-f6rHpdynqzOCj729Vfeb83s7KAYSpVXhbUdOkGtZUcMQ@mail.gmail.com>
To: "Black, David" <David.Black@dell.com>
Cc: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, Vincent Roca <vincent.roca@inria.fr>, The IESG <iesg@ietf.org>, Emmanuel Baccelli <emmanuel.baccelli@inria.fr>, "tsvwg@ietf.org" <tsvwg@ietf.org>, Belkacem TEIBI <belkacem.teibi@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000459938057fffb888"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/P0wD0y24VKpx2eXOMmf2qYcxjO4>
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: Mon, 21 Jan 2019 22:52:53 -0000

Hi, David,

On Mon, Jan 21, 2019 at 8:44 AM Black, David <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