Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary



Modifying an author's original work without specified permission;
regardless of new findings, coFrom ietf-bounces at ietf.org  Sat Dec 13 18:43:36 2008
Return-Path: <ietf-bounces at ietf.org>
X-Original-To: ietf-archive at megatron.ietf.org
Delivered-To: ietfarch-ietf-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 84FBD3A687F;
	Sat, 13 Dec 2008 18:43:36 -0800 (PST)
X-Original-To: ietf at core3.amsl.com
Delivered-To: ietf at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 287AD3A687F
	for <ietf at core3.amsl.com>; Sat, 13 Dec 2008 18:43:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.466
X-Spam-Level: 
X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=1.133, 
	BAYES_00=-2.599, GB_I_LETTER=-2]
Received: from mail.ietf.org ([64.170.98.32])
	by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id Q3PzL6oKy06j for <ietf at core3.amsl.com>;
	Sat, 13 Dec 2008 18:43:34 -0800 (PST)
Received: from mail-qy0-f11.google.com (mail-qy0-f11.google.com
	[209.85.221.11])
	by core3.amsl.com (Postfix) with ESMTP id 21D073A680E
	for <ietf at ietf.org>; Sat, 13 Dec 2008 18:43:33 -0800 (PST)
Received: by qyk4 with SMTP id 4so2202733qyk.13
	for <ietf at ietf.org>; Sat, 13 Dec 2008 18:43:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:received:received:message-id:date:from:to
	:subject:in-reply-to:mime-version:content-type
	:content-transfer-encoding:content-disposition:references;
	bh=bJzVeGQJ1SeoovMFD5NzR4gSclYHdSdwEBtt++a7NxI=;
	b=l+J71qdgSUfovUflFrcz0qMyPG6oXZ9R5Qdwo58p1WRSH4X2Eh6UrlCLiW4v7PRnhw
	WegDD0CFYoQy8D1ToS6twlysy9prNUBHo181oI0xa8VPipdeKtc5AillyGirOzi1wMH/
	b3LZhHYixSpS2hDQzeOpc7UkBy4WHm/4bgHmI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:in-reply-to:mime-version
	:content-type:content-transfer-encoding:content-disposition
	:references;
	b=vegL86RUFxjCfsav5m242PdLBdEP8AoLtqMd1gXJw+KlgbWg2h+c0xeYvHzJ9zTcX/
	PrwRXapSlRdh2xqZO66W+BpPdVOWI8pZxSBKvpmCmSOFJvqf2NLPVOkHYJjwZ0mEyjSt
	gvnukkT6FGqIiciUE/hi3Is4OuYk3vMn/T8aA=
Received: by 10.214.150.21 with SMTP id x21mr6678882qad.143.1229222606087;
	Sat, 13 Dec 2008 18:43:26 -0800 (PST)
Received: by 10.214.44.20 with HTTP; Sat, 13 Dec 2008 18:43:25 -0800 (PST)
Message-ID: <be653210812131843v14e348beu5ac2ec69f9f8307 at mail.gmail.com>
Date: Sat, 13 Dec 2008 21:43:25 -0500
From: "AJ Jaghori" <ciscoworkz at gmail.com>
To: "Christian Huitema" <huitema at windows.microsoft.com>, 
	"Scott Brim" <swb at employees.org>, 
	"lrosen at rosenlaw.com" <lrosen at rosenlaw.com>, 
	"ietf at ietf.org" <ietf at ietf.org>
Subject: Re: IPR Questions Raised by Sam Hartman at the IETF 73 Plenary
In-Reply-To: <8EFB68EAE061884A8517F2A755E8B60A198B2FBA1E at NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
MIME-Version: 1.0
Content-Disposition: inline
References: <20081211224832.C04F33A69BD at core3.amsl.com>
	<ED38349F-47E1-4A16-866C-7E408FE151E1 at multicasttech.com>
	<DE1EBB80D3F89D4427307614 at p3.int.jck.com>
	<87fxktxn7f.fsf at mocca.josefsson.org>
	<07892C8A-21AB-4C0D-98FF-2A8C92D450FB at multicasttech.com>
	<20081212201956.0CA2128C207 at core3.amsl.com>
	<8D78B6C7-DA00-482F-B318-B928B62DCF9F at cisco.com>
	<859EA61D3E604B948E9ADA2ABBFB4265 at LROSENTOSHIBA>
	<494415A5.60102 at employees.org>
	<8EFB68EAE061884A8517F2A755E8B60A198B2FBA1E at NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces at ietf.org
Errors-To: ietf-bounces at ietf.org

Modifying an author's original work without specified permission;
regardless of new findings, constitutenstitutes a copyright infringement.




On 12/13/08, Christian Huitema <huitema at windows.microsoft.com> wrote:
>> You can improve any technology you want, modulo IPR -- that's not the
>> point here.  The problem is taking existing copyrighted text and using
>> it as a base for describing your technology.
>
> That's indeed the problem we stumbled upon years ago. Suppose that a
> contributor has written a complete description of technology X, getting it
> published as a 100 pages RFC. A remarkable feat, and a great contribution to
> the community. A few years letter, the working group realizes that they like
> the technology, but would like to change a couple options. That normally
> translates into changing a paragraph or two, resulting in a new RFC, more
> than 90% identical to the previous one.
>
> Suppose now that for whatever reasons, the original author disagrees with
> the changes, or with the new management of the working group, or with the
> new editor. People are human, these things do happen. IANAL, but my
> understanding at the time was that the original copyright still applied to
> the original text, and that the working group would be left with only bad
> options. They could issue a delta RFC that only contained the modifications,
> but that is somewhat confusing for the readers. Or they could undertake a
> complete rewriting of the standard, but that takes a long time and is also
> prone to errors and confusion.
>
> This is very much why we got the statement on copyrights in RFC 1602, in
> 1996. You will notice that copyrights were only mentioned as something we
> might need to worry about later in the appendix of the previous rules, RFC
> 1310 published in 1992.
>
> -- Christian Huitema
>
>
> _______________________________________________
> Ietf mailing list
> Ietf at ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>


-- 
AJ Jaghori
Chief Network Architect | Author | Professor
ciscoworkz at gmail.com
M: 703.362.5002
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf


s a copyright infringement.




On 12/13/08, Christian Huitema <huitema at windows.microsoft.com> wrote:
>> You can improve any technology you want, modulo IPR -- that's not the
>> point here.  The problem is taking existing copyrighted text and using
>> it as a base for describing your technology.
>
> That's indeed the problem we stumbled upon years ago. Suppose that a
> contributor has written a complete description of technology X, getting it
> published as a 100 pages RFC. A remarkable feat, and a great contribution to
> the community. A few years letter, the working group realizes that they like
> the technology, but would like to change a couple options. That normally
> translates into changing a paragraph or two, resulting in a new RFC, more
> than 90% identical to the previous one.
>
> Suppose now that for whatever reasons, the original author disagrees with
> the changes, or with the new management of the working group, or with the
> new editor. People are human, these things do happen. IANAL, but my
> understanding at the time was that the original copyright still applied to
> the original text, and that the working group would be left with only bad
> options. They could issue a delta RFC that only contained the modifications,
> but that is somewhat confusing for the readers. Or they could undertake a
> complete rewriting of the standard, but that takes a long time and is also
> prone to errors and confusion.
>
> This is very much why we got the statement on copyrights in RFC 1602, in
> 1996. You will notice that copyrights were only mentioned as something we
> might need to worry about later in the appendix of the previous rules, RFC
> 1310 published in 1992.
>
> -- Christian Huitema
>
>
> _______________________________________________
> Ietf mailing list
> Ietf at ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>


-- 
AJ Jaghori
Chief Network Architect | Author | Professor
ciscoworkz at gmail.com
M: 703.362.5002
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www.ietf.org/mailman/listinfo/ietf



Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.