ietf
[Top] [All Lists]

Re: [Trustees] Objection to reworked para 6.d (Re: Rationale for Proposed TLP Revisions)

2009-07-22 07:24:39
    Date:        Wed, 22 Jul 2009 08:32:38 +0200
    From:        Harald Alvestrand <harald(_at_)alvestrand(_dot_)no>
    Message-ID:  <4A66B286(_dot_)9080003(_at_)alvestrand(_dot_)no>

I don't want to say much more on this issue, I suspect enough has
been said now, but just one final (from me) point ...

  | The working group's non-consensus on this point is documented in section 
  | 4.4 of RFC 5377:
  | 
  | 4.4.  Rights Granted for Use of Text from IETF Contributions
  | 
  |    There is no consensus at this time to permit the use of text from
  |    RFCs in contexts where the right to modify the text is required.  The
  |    authors of IETF Contributions may be able and willing to grant such
  |    rights independently of the rights they have granted to the IETF by
  |    making the Contribution.

I have no idea how to interpret that - one meaning might be that
contributors of code to the IETF can assume that the IETF will not
grant rights that allow modification of the text.   If that's how it
works out, then once again, whatever you think other parts of the
RFC say, contributors can rely upon that, and then the IETF cannot
later change its mind, and allow modification - the contributor gave
the code based upon the assumption that would not be permitted.

On the other hand, if we're all convinced that the contributor must be
giving the IETF the rights to do whatever it likes with the contribution,
including permitting modifications - then the IETF should be (and by
referring to a BSD like licence, in fact, is) allowing people do do
whatever they want with code in an RFC - which includes modifying it.

After all "there is no consensus to permit" also can be written with
the exact same meaning as "there is no consensus not to permit", that's
what "no consensus" means (though authors sometimes try to describe a
point where there's no agreement at all to make it look as if the result
of that should be what they think the outcome should be - which is what
the paragraph you quoted looks like to me.   That is, we couldn't get
people to agree to prohibit modifications, so we'll write a paragraph
that makes it look like the base position is to prohibit that, and then
make it clear that we didn't agree that distribution with modification
rights should be allowed - everyone will just conclude that it isn't
allowed...

That's bogus, and it looks to me (by use of the BSD licence, which if
the advertising clause were removed, which it should be (and is in the
current version of the BSD licence) about as liberal as it is possible to be.
That is, I cannot see it is possible to be more liberal (advertising
excepted, and that's a minor point) than the BSD licence which is being
specified.

Making it truly difficult to change makes it harder for the distribution
to be made more restricted, which looks to me to be just about the only
way it is possible to move (and if the advertising clause has been, or can
be quicky, removed from the IETF's version of the BSD licence, then we're
about as unrestricted as it is possible to get).

On the other hand, if the IETF's "BSD licence" is currently prohibiting
modifications, then it clearly is not a BSD licence at all (so you'd be
right, that name ought to be removed as being misleading) - and that ought
to be fixed, as quoted above (being read carefully) we have no consensus
to prohibit distribution with modifications permitted (unless the
contributors are not granting that right, of course) so we may as well
just allow modifications.

kre

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf