Re: draft-ietf-ipr-rules-update-00.txt

Brian E Carpenter <brc@zurich.ibm.com> Fri, 07 October 2005 13:34 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENsND-00052u-Ss; Fri, 07 Oct 2005 09:34:55 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENsNB-00052d-W9 for ipr-wg@megatron.ietf.org; Fri, 07 Oct 2005 09:34:54 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18194 for <ipr-wg@ietf.org>; Fri, 7 Oct 2005 09:34:49 -0400 (EDT)
Received: from mtagate2.de.ibm.com ([195.212.29.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ENsWS-0006jq-9R for ipr-wg@ietf.org; Fri, 07 Oct 2005 09:44:28 -0400
Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id j97DYed7175524 for <ipr-wg@ietf.org>; Fri, 7 Oct 2005 13:34:40 GMT
Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j97DYdcq181058 for <ipr-wg@ietf.org>; Fri, 7 Oct 2005 15:34:39 +0200
Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j97DYdhF013135 for <ipr-wg@ietf.org>; Fri, 7 Oct 2005 15:34:39 +0200
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j97DYdXg013119 for <ipr-wg@ietf.org>; Fri, 7 Oct 2005 15:34:39 +0200
Received: from zurich.ibm.com (sig-9-145-251-27.de.ibm.com [9.145.251.27]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA39200 for <ipr-wg@ietf.org>; Fri, 7 Oct 2005 15:34:38 +0200
Message-ID: <4346796B.8070702@zurich.ibm.com>
Date: Fri, 07 Oct 2005 15:34:35 +0200
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: ipr-wg@ietf.org
References: <20051003225658.30F823BFD0D@berkshire.machshav.com> <Pine.LNX.4.61.0510040819220.12046@netcore.fi>
In-Reply-To: <Pine.LNX.4.61.0510040819220.12046@netcore.fi>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Content-Transfer-Encoding: 7bit
Subject: Re: draft-ietf-ipr-rules-update-00.txt
X-BeenThere: ipr-wg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IPR-WG <ipr-wg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipr-wg>, <mailto:ipr-wg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipr-wg@ietf.org>
List-Help: <mailto:ipr-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipr-wg>, <mailto:ipr-wg-request@ietf.org?subject=subscribe>
Sender: ipr-wg-bounces@ietf.org
Errors-To: ipr-wg-bounces@ietf.org

Bundled replies:

Pekka Savola wrote:
...
> As for "is this the way to get there?" -- I'd say, initially (to 
> evaluate whether there is WG consensus or not) this is OK.  However, I 
> think we should consider re-spinning BCP 78 to add these provisions, or 
> at least create a new self-standing document.  I don't want to see the 
> IPR process documents ending up patchwork with no one able to figure out 
> where to find the patches and how they fit together.

Possibly, but note that it is entirely possible for a BCP (like an STD)
to consist of several RFCs. I used to think that wasn't so, but it
is allowed by BCP 9. So we can do whatever is more convenient.

Scott Bradner wrote:
...
> 
> Simon further sez:
>   The text suggest to me that IETF/ISOC has acquired
>   the right to grant sublicenses.
> 
> "will acquire" (since this applies going forward, but basically correct

Exactly. So in specific cases and on request, sublicenses could be granted.
They could be royalty free. They could allow extracts from an RFC to be
embedded in open source code. So the IETF would have the freedom to do this,
but not a requirement that contributors automatically grant such rights.

...
> Pekka sez:
>   In any case, the suggested revised section 3.3 (a) (C) does not
>   specify who makes that case-by-case judgment/consensus call. That seems
>   like an important detail which need to be specified.
> 
> I thought about that - I think its the IESG but can see cases where the
> IAB might be the right body so wanted to leave it open until I 
> saw some consensus - opinions?

I see an argument for "IESG or IAB" and I see an argument for "on the
advice of WG chairs or RFC authors".

Pekka Savola added:

 > Just a thought: is the IETF administrative director an option?  As (s)he
 > has considerable oversight, I guess the decision would get reviewed in
 > the appropriate places as need be.

I think that's wrong, actually. The IAD is likely to be the person
who phsyically signs a license but shouldn't be the decider; that's
for the technical side of the house.

C. M. Heard wrote:

 > Indeed.  As I read it, neither this language, nor that currently in
 > RFC 3978, viz.,
<snip>
 >
 > permits third parties to extract even unmodified MIB modules for
 > separate use.  Since that's something we _want_ people to do,
 > permission to do so should be explicit and automatic (i.e., not
 > requiring any special action by the IETF).  I originally thought we
 > had this covered in 3978, but I missed the language in 1(a) that
 > Simon Josefsson has emphasized.

It's clear to me that the IETF's desire, historically, has been
to allow extractions of unmodified code (e.g. MIBs) but not to allow
uncontrolled modifications - that's exactly why the emphasis is on
the right to make derivative works. The new language will give us
the right to license derivative works but will not hand blanket
permission to change our RFCs to unknown third parties. I think that's
the intention.

I can envisage that once this is signed and sealed, we could issue
a public license to extract MIB modules, for example. But completely
open blanket permission? I don't personally think that is desirable.

Simon Josefsson wrote:
...
 > The page also include a petition, if you want to indicate support of
 > this effort.

Contrary to what you may falsely deduce from other events, petitions are
not part of the IETF consensus process.

     Brian



_______________________________________________
Ipr-wg mailing list
Ipr-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg