Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem

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

 



At 13:13 09/01/09, Brian E Carpenter wrote:
>
>On 2009-01-09 13:59, Stephen Farrell wrote:
>> +1 to fred's proposal, let the exceptions be just that and don't bother
>> most I-D authors,
>> Stephen.
>> 
>> On 8 Jan 2009, at 22:49, Fred Baker <fred@xxxxxxxxx> wrote:
>> 
>>> You asked me to make this comment publicly, so here it is.

>>> From my perspective, the best approach involves keeping the general
>>> case simple. The documents that have been transferred outside the IETF
>>> in the past five years is a single digit number, a tenth of a percent
>>> of all RFCs if not a smaller fraction. 
>
>If that was the main problem, I would agree. But it isn't; it's the ability
>to allow appropriate use of extracts, including code extracts, in 3rd
>party documents.

First, my gut feeling would be that use of ABNF and similar stuff
in actual implementations might simply be considered fair use, or
it may just be possible to consider implementations as part of the
IETF standards process (which they very much are).

The situation may be somewhat different for longer/longish pieces
of code, a typical example of which might be Appendix A of
http://www.ietf.org/rfc/rfc2192.txt. But the code is essentially
there to serve as an example, as an additional guarantee that
there is a common, shared understanding of the specification,
not as a drop-in implementation. Also, such code in many
instances is already covered under a more appropriate licence
anyway.


>That potentially concerns every RFC,

Given the above (some of which might be a bit out on a limb, or not),
I'm still not convinced the potential issue is that big.

>and automatically
>concerns every RFC that is a new version of an older one.
>
>It isn't hard to fix in my opinion (well, I just posted a draft with
>the proposed fix) and I don't see that it *requires* any tool fixes.
>Optionally, the tools could provide a macro that expands to the
>disclaimer text, but cut-and-paste would work equally well.

I have read your draft. I have one suggestion for modification.
The text says:

                           "the person(s) controlling the copyright in
   such material have not granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process."

I think it might be more appropriate to change "the person(s)" to
"some person(s)".


Overall, I think currently the aspect most overlooked in the general
discussion, but most relevant for somebody who would actually like
to move on with publications (I'm both a WG chair with some drafts
that have completed WG Last Call, but which are now in "RFC 5378 limbo",
and an author of some individual IDs that I'd like to update
and move forward) is:

WHO exactly are we supposed to get permissions from.

The situation of a deceased author is a tought one, but it's an
obvious one. But I haven't seen any clear answer to whether
permission from all the authors/editors (the people listed in
the front of the document) is sufficient, whether we have to
ask everybody above a certain percentage of email contributions
in the WG, everybody who's mentioned in the Acks section, or
what. It's a significant nuissance for everybody to go around
and beg people (maybe including for their former employer)
to confirm something they probably couldn't care less, even if
they otherwise think the IETF does great stuff and everything.
So it would really be good to know who exactly has to be
bothered, and who not.

Regards,    Martin.



#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst@xxxxxxxxxxxxxxx     

_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]