Re: [Trustees] Change in IPR policies

John C Klensin <john-ietf@jck.com> Wed, 10 June 2020 04:20 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A1C3A0E39; Tue, 9 Jun 2020 21:20:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 MEuBgk61Wmn1; Tue, 9 Jun 2020 21:19:58 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91B923A0E36; Tue, 9 Jun 2020 21:19:58 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1jisDU-0001cx-KR; Wed, 10 Jun 2020 00:19:56 -0400
Date: Wed, 10 Jun 2020 00:19:51 -0400
From: John C Klensin <john-ietf@jck.com>
To: Brad Biddle <brad@biddle.law>, Jay Daley <jay@ietf.org>, llc-board@ietf.org
cc: Trustees <trustees@ietf.org>, ietf <ietf@ietf.org>
Subject: Re: [Trustees] Change in IPR policies
Message-ID: <EBEE9A1994B9DA65F98FF437@PSB>
In-Reply-To: <CAPdOjkhW-6WO1fzV3iO0ikGSSL3H-k1eUKZ0hRRApHMRwS6cWg@mail.gmail.com>
References: <96A3BDFE6F7DC38D2366581F@PSB> <45F719DA-115A-40C7-B96F-7F2D06E33199@ietf.org> <030e01d63e9f$9fcf3f50$df6dbdf0$@olddog.co.uk> <13080222-C9C3-44C6-B78C-AEE272639E51@ietf.org> <032e01d63ea7$534b4270$f9e1c750$@olddog.co.uk> <859539A9-ACD2-4E69-8657-7D4A7FE899B6@ietf.org> <CAPdOjkhW-6WO1fzV3iO0ikGSSL3H-k1eUKZ0hRRApHMRwS6cWg@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/vOYcqJYrqmQwp131qONBZW9nsds>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
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, 10 Jun 2020 04:20:01 -0000

So, Jay and Brad,

Obviously legal counsel was consulted.   Were the Trustees of
the IETF Trust, who are supposed to be responsible for any IPR
that the IETF owns sufficiently to make rules about what can be
done with it, consulted?

My understanding of role of the IETF Administration LLC, from
the day the IASA2 WG effort started (if not a bit earlier) is
that the relationship between the LLC and the IETF rested on two
critical principles: The LLC does not take any actions that
could interfere with or change the standards process.  And
responsibility for the IETF's IPR and decisions about
circumstances in which it can be utilized or restricted belong
exclusively to the processes that produced BCP 78 and 79 (and
that might create updates or revisions to them in the future),
to the IETF Trust, and to Trustees who are accountable to the
community.

Mistakes get made and it is unsurprising that humans, especially
humans who are dealing with unusual circumstances, stress, and
the pressure or time will sometimes make them.  When those
mistakes are pointed out, their swift correction is much
appreciated (at least by me and I hope by others).  However
--and I am addressing this much more to the LLC Board than to
Jay and/or Brad-- it is, at least IMO, your job, whether
explicit in the many IASA2 documents or not, to ensure that your
staff and your contractors are sufficiently educated about the
IETF to understand those boundaries.  Part of that is that the
LLC leadership and staff are not "in charge of the IETF".  The
IESG has a much better claim to that responsibility and
authority, but the procedures and traditions significantly even
constrain even them.   Just my opinion but, because of how the
IETF works and its mission and credibility, while the LLC
obviously has to be fiscally responsible, if there are choices
between a possible incremental few dollars and openness and
inclusiveness or between trying to pass rules to prevent people
from abusing the system and trusting that active IETF
participants will behave like responsible professionals, the
decisions should favor openness, inclusiveness, and assumptions
that people will behave professionally.    If people don't
behave professionally, we have a different sort of problem but,
at least in theory, we have ways to deal with that and, fwiw,
they are not the LLC's problem (or within the LLC's scope)
either.

If the LLC cannot take responsibility for keeping those
boundaries clear, then I think the LLC plan was a mistake and
the IETF community has a rather serious problem.

Finally, please consider that the proposed (now removed) policy
requirement might even make poor fiscal sense.    Suppose there
is some large company or organization that had been supporting
the IETF (perhaps via donations to ISOC) for years but also had
personnel who participated in the IETF's technical work (as you
know, there are several such companies).  Suppose those people
and their management had established a practice of using
recordings of IETF sessions for internal briefings about the
IETF's work.  Now we come along and say what might be heard as
that "the IETF has started to count beans and distrust that our
employees will use information responsibility".   If a corporate
executive got that information and overreacted it could easily
result in restrictions on IETF participation by company
employees and/or the end of those donations.   That scenario is,
I assume and hope, rather unlikely but so (given the comments
about professionalism above and elsewhere) are the odds of
collecting more than a handful of extra registration fees from
people who would otherwise beat the system.  Trading the
possible benefit of collecting even a few thousand dollars in
extra fees against the possible loss of, say, a $50K
contribution suggests that this is the wrong way to think about
the issues even if all of the non-fiscal considerations were
ignored.

thanks for listening,   
   john



--On Tuesday, June 9, 2020 15:44 -0700 Brad Biddle
<brad@biddle.law> wrote:

> Let me add an apology from the legal side. We provided fairly
> generic language we've used in other contexts without
> carefully considering the unique culture, technical
> circumstances and IPR dynamics of the IETF. We'll be more
> mindful of this going forward.
> 
> --Brad
> (IETF counsel)