[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Effort to change IETF's copying conditions for RFCs



Paul TBBle Hampson <Paul.Hampson@anu.edu.au> writes:

> On Thu, Oct 06, 2005 at 11:16:03PM -0700, Russ Allbery wrote:
>> Henrique de Moraes Holschuh <hmh@debian.org> writes:
>>> On Thu, 06 Oct 2005, Russ Allbery wrote:
>
>>>> Unlimited distribution isn't the problem.  Modification and
>>>> redistribution of modified versions is the problem, and that
>>>> restriction was apparently
>
>>> If the IETF allows modified versions that are *RENAMED*, then it would
>>> meet the DFSG.  They can even restrict the renaming to "something that
>>> makes it clear that this is not an RFC, STD, <insert other IETF acronyms
>>> here>"...
>
>> Right, I know.  Apparently it was intentional on the part of the IETF to
>> not even allow that.  Don't look at me; I think it's a stupid decision.
>
>> I'm not saying we can't get them to change it, or that we shouldn't try,
>> or anything else that discouraging.  I'm just saying that it isn't solely
>> a misunderstanding or lack of clarity; there really is an underlying
>> disagreement here.
>
> If the IETF doesn't even want people distributing modified, clearly
> indicated derived works, then how do people work on 'bis' versions of
> RFCs? eg. 2326bis, 'draft-ietf-mmusic-rfc2326bis-02.txt' is the old
> version I have lying around here now, which is clearly a derived work of
> RFC2326.

The license permit publishing derived works through the IETF process.

> Of course, this might be an IETF document, and _they_ are free to modify
> their own documents. I don't know that much about the IETF's processes,
> but it seems that denying the right to derive works from IETF standards
> documents is counterproductive, while restricting the naming of derived
> works to avoid confusion is understandable.

Yes.  I don't know how to achieve one without the other.  I'm not sure
why the IETF appear so afraid of someone taking a RFC, modifying it
and claiming it is the canonical version.  It won't happen because it
is pointless to do so.  And even if someone where to do it, the IETF
could simply sue them for claiming the IETF support something it
doesn't.  There is no need to restrict RFC copying permissions.

> Then again, do we want people forking RFCs? ^_^

Well, if the IETF doesn't permit modification of technical
specifications that the free software community needs, we will write
our own technical specifications that we can use.  They may not be as
complete as the RFC, but they will serve its point of documenting the
part of the protocol that end-users will have to care about.  If that
happens, the IETF has started to lose authority over protocol
standardization, so I think it would be in the best interest of IETF
to change their copying permissions.

Thanks,
Simon



Reply to: