Subject: Re: Preventing Fake RFCs - Proposal

From: [email-masked]
Date: Wed, 16 Nov 2005 14:45:00 +0000

Brian - the trademark is actually pretty important to the larger picture though especially for the materials in the trust.

Todd

 -------------- Original message ----------------------
From: Brian E Carpenter <[email-masked]>
> I'd like a legal opinion on that, but it seems much more
> practical than attempting to use trademark law as some have
> suggested.
> 
>      Brian
> 
> [email-masked] wrote:
> > I have an idea for separating out the "prevention of fake
> > RFCs" issue from the rest of the issues we're working
> > on and solving it.  I observe:
> > - Any fake RFC needs the "boilerplate", otherwise it's
> > 	not a credible fake.
> > - None of the RFC extracts need the "boilerplate" (or at
> > 	least don't need it in its entirety).
> > - The "boilerplate" is controlled by the IETF.  Nobody
> > 	else can grant permission to use it.  That's not
> > 	the case for most other RFC text.
> > 
> > So, I suggest putting restrictive license conditions on
> > documents that contain the "boilerplate" (or just some crucial
> > piece of it like the various "Status of this Memo" texts that
> > appear on the first page of RFCs and I-Ds):
> > - The "boilerplate" is for use on RFCs and Internet-Drafts.
> > 	All other uses are prohibited.
> > - Documents (RFCs and Internet-Drafts) containing the
> > 	"boilerplate" may be modified outside the IETF
> > 	in a fashion that retains the "boilerplate", only
> > 	for:
> > 	- formatting for publication
> > 	- translation
> > 	- creating Internet-Drafts to submit to the IETF.
> > 	All other modifications outside the IETF that
> > 	retain the "boilerplate" are prohibited.
> > Extracts (modifications that remove the "boilerplate")
> > can then be dealt with separately without fear of
> > enabling fake RFCs, because any such fake RFC either
> > contains the boilerplate, and hence violates the license
> > conditions, or doesn't contain the boilerplate and hence
> > can't be taken seriously as a fake RFC.
> > 
> > The result should be more flexibility in the options
> > for permitting extracts and modified extracts outside
> > the IETF because the permissions we grant don't have
> > to consider preventing fake RFCs.
> > 
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > [email-masked]        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> > 
> > _______________________________________________
> > Ipr-wg mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ipr-wg
> > 
> 
> 
> _______________________________________________
> Ipr-wg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipr-wg

_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: [email-masked]
Date: Wed, 16 Nov 2005 12:59:59 -0500

>> The restrictive license I'm proposing on the "boilerplate" goes beyond
>> prohibiting modifications to the "boilerplate" itself to prohibit
>> modifications elsewhere in the RFC when the "boilerplate" is retained
>> in the result.
>
> Ouch.  You are right.  Still, I believe there is a chance that this
> solution may be acceptable to everyone.
> 
> You would still be permitted to modify the content of the RFC, if you
> remove the boiler plate, right?

Yes.  Something completely different would grant permission to create
RFC extracts that don't contain the boilerplate.  I'm still thinking
about and working on that ...

> This situation seem similar to requests that I recall in some licenses
> that confusing author or name information should be removed if you
> modify the work.  I recall that some projects required that if you
> release a modified work, you would have to remove all references to
> the original name.  You can't call it X any more, which imply several
> changes of the work.  I think that is considered to be acceptable in
> the free software community.

That's useful to know.

Thanks,
--David

---

From: [email-masked]
Date: Wed, 16 Nov 2005 21:56:43 -0500

> Sam why dont we just write a release to the OpenSource TCP/IP Stack
vendors
> that allows them to republish the IETF RFC's as a part of their
> documentation as long as they are printed in whole and bear the IETF's
> copyright mark. Then we can take the OpenSource User's Republishing Rights
> component out of this equation.

That's almost exactly where the proposal in this thread is headed, except
that it would allow anyone to republish RFCs, not just open source
distributors.
To the extent that there is an open issue (and it's a minor one), see Sam's
and Simon's concerns that Debian (and other similarly situated open source
distributors) might not accept such conditions for RFC redistribution, and
would hence choose not to redistribute RFCs under those conditions.

My sense of the discussion is that there's a strong sentiment that Debian
should accept such conditions if it wants to redistribute RFCs, and that
if Debian instead chooses not to redistribute RFCs, the ready availability
of RFCs via the web would make a possible Debian decision not to distribute
RFCs a problem for Debian, not the IETF.  Note: This is NOT the case for
RFC extracts, especially those that go into source code.

In any case, the whole point of this thread has been to take the "fake RFCs"
issue out of the "RFC extracts" discussion.  Simon's working on text for
his draft, and there will be discussion of this in the draft I'm working
on.

Thanks,
--David