Re: RFC 5378 "contributions"
TSG <tglassey@earthlink.net> Thu, 15 January 2009 17:11 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6380D3A69AA; Thu, 15 Jan 2009 09:11:26 -0800 (PST)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A87C83A69AA for <ietf@core3.amsl.com>; Thu, 15 Jan 2009 09:11:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 B3s8DX-fMPuy for <ietf@core3.amsl.com>; Thu, 15 Jan 2009 09:11:24 -0800 (PST)
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id D0DCE3A691C for <ietf@ietf.org>; Thu, 15 Jan 2009 09:11:23 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=GoXHbNBdZAevhOzp5/M3FhJHUnaW86H8M2aShbK+Uqz3TJA6kvuyvvm+Pg8CuXng; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP;
Received: from [64.125.79.23] (helo=[192.168.0.32]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <tglassey@earthlink.net>) id 1LNVjp-0005xY-PD; Thu, 15 Jan 2009 12:10:38 -0500
Message-ID: <496F6E09.60708@earthlink.net>
Date: Thu, 15 Jan 2009 09:10:33 -0800
From: TSG <tglassey@earthlink.net>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Marshall Eubanks <tme@multicasttech.com>
Subject: Re: RFC 5378 "contributions"
References: <50E312B117033946BA23AA102C8134C6031B3970@SDCPEXCCL2MX.wilmerhale.com> <20090115035256.GB81320@shinkuro.com> <CFD40B6FB7A87F31F3D9CABE@PST.JCK.COM> <0882F36F-6800-4E5E-BC9F-EBA8C7D1877D@multicasttech.com> <20090115142929.GE30522@mit.edu> <D01F4A5C-9507-4005-B4A0-C00CE2E6973E@multicasttech.com>
In-Reply-To: <D01F4A5C-9507-4005-B4A0-C00CE2E6973E@multicasttech.com>
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec794e6195de11b87c90d1bb16d21f5625e3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 64.125.79.23
Cc: John C Klensin <john-ietf@jck.com>, Theodore Tso <tytso@mit.edu>, ietf@ietf.org
X-BeenThere: ietf@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@ietf.org?subject=unsubscribe>
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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
Marshall Eubanks wrote: > > On Jan 15, 2009, at 9:29 AM, Theodore Tso wrote: > >> On Thu, Jan 15, 2009 at 08:24:08AM -0500, Marshall Eubanks wrote: >>> On Jan 15, 2009, at 7:09 AM, John C Klensin wrote: >>> >>>> If someone stood up in a WG prior to whenever 5378 was >>>> effective* and made a suggestion of some length, or made a >>>> lengthy textual suggestion on a mailing list, and I copied that >>>> suggestion into a draft without any paraphrasing, a plain-sense >>> >>> John, I am not a lawyer, you are (AFAIK) not a lawyer, and if the >>> IETF counsel says otherwise, I would just let this one lie. >>> >>> The reason why I do not agree with this reasoning is that these >>> rights are claimed through authorship. If I do not claim authorship >>> in your draft because you use my text, when I have ample opportunity >>> to do so, then I have (in my opinion) effectively lost them, >>> especially in this context (where there is a note well, an >>> assumption of joint contributions, etc.). >> >> So it's a problem if every single I-D and RFC author is going to have >> to consult their own counsel before deciding that won't get into legal >> trouble when guaranteeing that all of their text is appropriately >> licensed. >> > > This is an IETF list, to discuss matters of relevance to the IETF. > Whether or > not you need to consult counsel is not really on topic, and for sure > you should not > make that decision based on what anyone (especially me!) says on this > list. > > If, on the other hand, you do obtain advice of counsel on this matter > I would be curious to > learn what they say. > >> So whether or not I am I lawyer, and whether or not the Berne >> Convention very clearly states that copyright rights are automatically >> >> enforced, and do not need to be explicitly claimed, and whether or not >> the Note Well is enough to override the Berne Convention, John's >> position that he wants to be conservative enough not to make >> guarantees that might expose him to legal liability is a reasonable one. >> >> I don't think it's fair to say, "I'm not a lawyer, and you're not a >> lawyer" so you should do something which you fear exposes you to legal >> risk --- especially when all of the IP training many of us have gotten >> have basically told us that the Berne Convention explicitly states >> that you don't have to claim copyright to get copyright protections.... >> >>> Yes, I am sure that there are corner cases here, but one thing >>> I have found about legal affairs is that there are always corner cases. >>> No legal matter is ever sewn up 100%, and judges actually do take into >>> consideration when things are done "on advise of counsel." We have it, >>> we should use it. >> >> Has the IETF Counsel actually given explicit legal advice to all IETF >> contributors (which would have legal liability implications for the >> IETF Trust if said advice was wrong, as I understand things) that the >> Note Well to guarantee the transfer of RFC 5378 rights for text taken >> from IETF mailing list discussions or at an IETF meeting? >> >> Better yet would be if the IETF Trust was willing to ***indemnify*** >> I-D and RFC authors that they are on firm legal ground for asserting >> that they have all RFC 5378 rights when they take text from an IETF >> mailing list discussion or IETF face-to-face meeting, on the basis of >> the Note Well. After all, it is the IETF Trust which is requiring I-D >> and RFC authors to make this legal guarantee, so one might assert that >> in a fair world they should take the legal risks associated with that >> guarantee. >> > > Consider the threat model here. > > This threat applies ONLY to material that the Trust licenses to third > parties (such as, say, > the IEEE) for inclusion and modification in their standards. (Just > reprinting or translating an RFC is not at issue.) > > Suppose that you author an RFC today, and use pre-5378 material, and > warrant (in good faith) that the Trust has a license for that > material, or apply a legend from the Trust that says that these rights > are not obtainable by you, and it happens that the original author of > that earlier material disagrees with this license to a third party. > Note that these earlier author's (and their companies) agreed to > freely use this material in the IETF process (the note well, etc.), > and so you have no risk just by publishing the RFC as long as it is > not licensed to other parties. > > The Trust would be the party that would be licensing this material to > third parties, so clearly > the Trust would be the major party at risk. What is your risk ? > > There is a theoretical risk that the Trust might sue you. That is one > thing that the work-around is intended to remove. > > There is an actual risk that a third party might sue you and the Trust > - specifically, that the original author or their heirs, etc., might > sue. They can only do this if there is infringing use, and that would > have to be based on a license from the Trust. > > If the Trust does NOT license your material to third parties, then > there is no infringement, no one with standing to sue, and no risk to > authors. It may be necessary for the Trust to state that they will not > assume 5378 to be in place for this purpose until there is a > replacement. (In that case, if the IEEE or some other body wants to > take over an RFC and modify it, they will have to get explicit > permission from all authors until there is a replacement for 5378 in > place, just as they did before 5378 as put into place.) My > understanding is that the Trust is responsible for these licenses, and > so they could just (in their best judgement) refuse to issue them > without further conditions. > > These requests are very infrequent (less than 1 RFC per year is my > understanding) and doing this would NOT stop the work of the IETF. I > am beginning to feel that this may be a necessary step. > > What about going forward ? Should we (the IETF, through the Trust) > indemnify authors ? > > Indemnification in practice translates to insurance. The Trust has > insurance for its activities. I dont believe that is true. Since those policies would continuously have to be reviewed by the Underwriter every time anything under the trust changed. http://www.products-liability-insurance.com/abatement-defense-qa.php See also http://www.premier-source.com/ip-defense-insurance The problem the IETF faces is that its "current IP intake processes" probably will not be insurable IMHO based on the refusal to put proper contractual conveyance processes and the proper mandatory disclosure requirement's in place. > I personally think it would be wise for the Trust to investigate > whether it could obtain insurance > for all authors _of materials licensed to others_ (post 5378 or post > some later RFC), what it would cost, and whether the insurers would > want changes in our procedures. (I would feel more comfortable if we > just learned that our processes were insurable, even if we did not > actually get insurance.) Sure - this is about ownership issues. There is insurance available for perfecting ownership rights. Its pretty expensive these days. And again since the IETF's IP staff refuses to perform those Risk Analysis which come with the creation of use process models for the IP it codifies, every time something changes in the operations of the Trust, the underwriting will have to be redone. Personally I figure litigation against the IETF to run in the $300k to $500K region based on the number of people who would fight back to try and cover up the various frauds and damages their employee's possibly were directly and indirectly involved with inside the IETF. The problem is that for each RFC published there would be a need to insure it's submission to the trust meaning we are looking at several hundred thousand dollars PER RFC or I-D filed with the Publishing Desk of the IETF's Trust. > > Given that the Trust is insured for its handling of ALL IETF work, and > this extra insurance would be for maybe 1 RFC per year, the cost to do > this might be very reasonable. I don't know, but I would urge the > Trust to find out. So then the Trust and its officers are NOT insured for anything now right? That means they and their sponsors bear all financial responsibilities for IP Damage to the owners of IP which is wrongly submitted to the IETF. A submission without perfecting the Ownership cannot convey actual title to that IP to the trust... and that is the issue here I think. > > Or (and this is my opinion), maybe the authors should only warrant > _their work_ as being subject to such licenses, and put the burden on > the Trust to obtain any necessary approvals from other parties, only > alerting the Trust to the extent they know of such prior authorship. > My understanding is that this would require a 5378bis. > > Again, please note that I am trying to discuss what the Trust and the > IETF should do, not what you or other individuals should do. > >> - Ted > > Regards > Marshall > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > ------------------------------------------------------------------------ > > > Internal Virus Database is out of date. > Checked by AVG - http://www.avg.com > Version: 8.0.176 / Virus Database: 270.10.4/1880 - Release Date: 1/7/2009 8:49 AM > > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- RFC 5378 "contributions" Randy Presuhn
- Re: RFC 5378 "contributions" Brian E Carpenter
- Re: RFC 5378 "contributions" Marshall Eubanks
- Re: RFC 5378 "contributions" Paul Hoffman
- Re: RFC 5378 "contributions" Contreras, Jorge
- Re: RFC 5378 "contributions" Andrew Sullivan
- Re: RFC 5378 "contributions" Randy Presuhn
- Re: RFC 5378 "contributions" Tom.Petch
- Re: RFC 5378 "contributions" Harald Alvestrand
- Re: RFC 5378 "contributions" Martin Duerst
- Re: RFC 5378 "contributions" John C Klensin
- Re: RFC 5378 "contributions" TSG
- Re: RFC 5378 "contributions" Marshall Eubanks
- Re: RFC 5378 "contributions" Andrew Sullivan
- Re: RFC 5378 "contributions" Theodore Tso
- Re: RFC 5378 "contributions" Theodore Tso
- RE: RFC 5378 "contributions" Contreras, Jorge
- Re: RFC 5378 "contributions" John Levine
- Re: RFC 5378 "contributions" Marshall Eubanks
- Re: RFC 5378 "contributions" TSG
- Re: RFC 5378 "contributions" TSG
- Re: RFC 5378 "contributions" Theodore Tso
- Re: RFC 5378 "contributions" Doug Ewell
- Re: RFC 5378 "contributions" Simon Josefsson
- Re: RFC 5378 "contributions" Tom.Petch
- Re: RFC 5378 "contributions" Marshall Eubanks
- Re: RFC 5378 "contributions" Marshall Eubanks
- Re: RFC 5378 "contributions" Theodore Tso
- Re: RFC 5378 "contributions" SM
- Re: RFC 5378 "contributions" Simon Josefsson
- Re: RFC 5378 "contributions" Tom.Petch
- Re: RFC 5378 "contributions" John C Klensin
- Re: RFC 5378 "contributions" Theodore Tso
- Re: RFC 5378 "contributions" Simon Josefsson
- Re: RFC 5378 "contributions" Theodore Tso
- Re: RFC 5378 "contributions" Simon Josefsson
- Re: RFC 5378 "contributions" TSG
- Re: RFC 5378 "contributions" Tom.Petch