Subject: Re: [tsvwg] Mirja Kühlewind's Discuss on draft-ietf-tsvwg-rlc-fec-scheme-09: (with DISCUSS)

From: "Black, David" <[email-masked]>
Date: Mon, 5 Nov 2018 01:28:04 +0000

Following up on this - looking at the code, like Adam, I'm reasonably confident that I'm looking at a standard BSD 3-clause license (see https://en.wikipedia.org/wiki/BSD_licenses):

> > The license on the code in this document is a simplified BSD license, which
> appears to contain the exact provisions indicated in the TLP.

That said, I'm happy to defer to the IETF Trust's legal counsel to double-check that, as part of Adam's suggestion:

> > But, after giving it additional thought, it's probably worth at least making a
> request of the IETF's legal counsel to review the situation and provide input.

Specifically, I would ask that the IESG *please* take responsibility for working this Discuss concern with the IETF Trust with the goal of getting to a "Yes, that's ok" answer.

If we can't accept BSD-licensed code in an RFC, then something is very wrong, and the IESG and the IETF Trust need to fix it, not the authors of this draft.

Thanks, --David (tsvwg WG co-chair)

> -----Original Message-----
> From: Mirja Kuehlewind (IETF) [mailto:[email-masked]]
> Sent: Thursday, October 11, 2018 7:41 AM
> To: Adam Roach
> Cc: The IESG; [email-masked]; [email-masked]; Black, David; tsvwg-
> [email-masked]; [email-masked]
> Subject: Re: Mirja Kühlewind's Discuss on draft-ietf-tsvwg-rlc-fec-scheme-09:
> (with DISCUSS)
> 
> 
> [EXTERNAL EMAIL]
> Please report any suspicious attachments, links, or requests for sensitive
> information.
> 
> 
> I agree, it would be nice to have some review from a legal counsel on this. I was
> aware that BSD license for code was meant to be compatible with the IETF
> license (also I didn’t manage to quickly find all the references you provided
> below; thanks for that!). However, it seems still incorrect to me to have two
> different copyright statements that apply. I guess the other approach would be
> to see the code in the appendix as a literal citation and therefore the IETF
> copyright would not apply to that part. But not sure if that works that way…?
> 
> 
> 
> > Am 10.10.2018 um 20:08 schrieb Adam Roach <[email-masked]>:
> >
> > On 10/10/18 10:39 AM, Mirja Kühlewind wrote:
> >> I'm really not an expert on legal questions and get easily confused myself but
> >> I think just copying in the code including the copyright into the draft
> >> appendix leads to conflicting copyright statements, as the all content of the
> >> draft has the following copyright:
> >>
> >>    Copyright (c) 2018 IETF Trust and the persons identified as the
> >>    document authors.  All rights reserved.
> >>
> >> And the code says this:
> >>
> >>   * Copyright (c) 2011, 2013 Mutsuo Saito, Makoto Matsumoto,
> >>   * Hiroshima University and The University of Tokyo.
> >>   * All rights reserved.
> >>
> >>
> >
> > I had a similar concern, and was very close to making a related comment.
> Here's what I uncovered in trying to figure it out.
> >
> > BCP 78 §6 [1] indicates:
> >
> >
> >>    It is also important to note that additional copyright notices are
> >>    not permitted in IETF Documents except in the case where such
> >>    document is the product of a joint development effort between the
> >>    IETF and another standards development organization or is a
> >>    republication of the work of another standards development
> >>    organization.  Such exceptions must be approved on an individual
> >>    basis by the IAB.
> >>
> >
> >
> > The TLP [2] §4, however, provides for the notion of code explicitly opting in to
> a BSD license for code components:
> >
> >> If a licensee elects to apply the BSD License to a Code Component, then the
> additional licenses and restrictions set forth in Section 3 and elsewhere in these
> Legal Provisions shall not apply thereto
> > ...and the traditional way to opt into a BSD license is to include it with the code
> in question as a comment block.
> >
> >
> > I also note that the IESG has issued guidance [3] subsequent to the publication
> of BCP 78 that appears to be an attempt to clarify the situation:
> >
> >> The TLP requires copyright notice in IETF Documents, but not necessarily in
> each code component within an IETF Document. Authors may choose to include
> a copyright notice as a comment when a significant amount of code is collected
> together.
> >
> >
> > The license on the code in this document is a simplified BSD license, which
> appears to contain the exact provisions indicated in the TLP. The one thing that
> remains muddy for me is whether the phrasing in the TLP is meant to explicitly
> indicate the literal text to appear on the copyright line, or if the variation in this
> document is allowable. Given that the nature of the BSD license is such that it
> provides rights to everyone (including the Trust) that would allow its use as
> envisioned by the TLP, I decided that it was unlikely to be an issue.
> >
> > But, after giving it additional thought, it's probably worth at least making a
> request of the IETF's legal counsel to review the situation and provide input.
> > ____
> > [1] https://tools.ietf.org/html/rfc5378#section-6
> > [2] https://trustee.ietf.org/license-info/IETF-TLP-5.htm
> > [3] https://www.ietf.org/blog/iesg-statement-copyright/

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 5 Nov 2018 09:26:50 +0700

Hi David,

we did follow up with the legal counsel and the outcome was that the copyright statement is not compatible with the IETF copyright (this is not about the license but the copyright statement included). The problem is here specifically that this is third party code (not by the authors) and that’s where the conflict comes from.

I guess the resolution is to remove the code and refer to an external source or take the revenant part of the code and turn it into pseudo code. Please follow up with Spencer as the responsible AD.

Thanks!
Mirja

> Am 05.11.2018 um 08:28 schrieb Black, David <[email-masked]>:
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 5 Nov 2018 10:58:31 +0700

Just to confirm,

On Mon, Nov 5, 2018, 09:27 Mirja Kuehlewind (IETF) <[email-masked]
wrote:

> Hi David,
>
> we did follow up with the legal counsel and the outcome was that the
> copyright statement is not compatible with the IETF copyright (this is not
> about the license but the copyright statement included). The problem is
> here specifically that this is third party code (not by the authors) and
> that’s where the conflict comes from.
>
> I guess the resolution is to remove the code and refer to an external
> source or take the revenant part of the code and turn it into pseudo code.
> Please follow up with Spencer as the responsible AD.
>

That suggestion was made, and IIUC was made for two reasons.

First, the licensing issue (noted).

Second, experience from OPUS, where the code was the spec, as it is here.

All the OPUS implenenters made changes that weren't in that code, and
weren't made in other implementations, and when the working group wanted to
make changes TO THE SPEC, WHICH WAS THE CODE, everyone had to figure out
what the impact was to all the implemenations, rather than changing
psuedocode and letting all the implementers react as seemed right for each
implementer.

I have a funny story about agreeing we will have pizza and each of us
deciding what ingredients each of us will have on our own pizza, compared
to agreeing what all of us will have on a common pizza, that probably
applies here ...

Make good choices.

Spencer

Thanks!
> > Following up on this - looking at the code, like Adam, I'm reasonably
> confident that I'm looking at a standard BSD 3-clause license (see
> https://en.wikipedia.org/wiki/BSD_licenses):
> >
> > That said, I'm happy to defer to the IETF Trust's legal counsel to
> double-check that, as part of Adam's suggestion:
> >
> > Specifically, I would ask that the IESG *please* take responsibility for
> working this Discuss concern with the IETF Trust with the goal of getting
> to a "Yes, that's ok" answer.
> >
> > If we can't accept BSD-licensed code in an RFC, then something is very
> wrong, and the IESG and the IETF Trust need to fix it, not the authors of
> this draft.
> >