Re: [Ltru] IPR mumbles..

["Randy Presuhn" <randy_presuhn at mindspring.com>]

Hi -

As co-chair...

> From: "Phillips, Addison" <addison at amazon.com>
> To: "Randy Presuhn" <randy_presuhn at mindspring.com>; "LTRU Working Group" <ltru at ietf.org>
> Sent: Sunday, February 15, 2009 9:30 PM
> Subject: IPR mumbles..
...
> > > Since we include the 6.c.iii mumble, I have applied the
> > > noDerivatives200811 IPR directive.
> > 
> > I do not think we want that, since that would hamstring attempts to
> > revised it in the future. 
> 
> I don't think that's entirely true. The IETF Standards Process
> is explicitly excluded from the derivative works text, at least
> in 6.c.iii.  At the same time, 6.c.iii has an explicit no-derivatives 
> section to it. IANAL, but since 6.c.iii prohibits derivatives, I
> don't see how I can check 'trust200811'?? Can I get guidance
> on this? In the meantime, I can remove the additional no-derivatives
> text and just use 6.c.iii.
...

6.c.i and 6.c.iii differ *significantly* in the extent of their limitation
on derivative works.  The 6.c.i option is *not* appropriate for our purposes.
It's intended for someone who wants to get something published as an RFC, but not
allow derivative works other than RFC formatting and translations.  The 6.c.iii
option places a limitation on the development of derivative works *outside*
the IETF process. The ability to produce derivative works outside the IETF
process was something added with RFC 5378, and the necessary permissions
were not in effect when contributions were made prior to RFC 5378.  Thus
a document which contains "pre-RFC 5378 material" can live up to RFC 5378's
requirements only if:
   (a) all the contributors of the older material explicitly grant those
       rights (raising the question of who those contributors are and
       how to track them down)
   -or-
   (b) we put in the disclaimer acknowledging the situation, and effectively
      withdrawing the document for consideration for spin-off to some other
      standards body.

(b) seems the correct choice in our case, and that is what the 6.c.iii option
is for.  The 6.c.iii text does *not* limit what we can do inside the IETF
standards process.

The limitation on derivative works in 6.c.iii would only kick in, for example,
if the IETF were to hand off responsibility for the language subtag registry
procedures to, say, the W3C.  Otherwise, for our purposes everything else
continues to work pretty much the way it always has.

Randy