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

Re: Outgoing section 5.5 and draft-josefsson (Re: San Diego meeting slot)



Unfortunately, the code often contains normative information, and very frequently is very helpful for actually understanding the RFC. I can not see, for example, moving the MIB to an attachment to an RFC. Without the MIB text, there is no substance. Hence, I think it would be a very bad idea to require that all code that is to be modifiable (as per the WG rough consensus) be in a separate attachment.

I have no problem with having references to code that has other, more restrictive licenses.

And I am willing to let the IAOC and the lawyers figure out what the best way is to meet our stated goals (RFC text useable without modification, RFC code useable in any way desired including modifications.) If they come back and say it can't be done, then we try again. But since I have seen several ideas on the list which seem likely to work, I see no reason to change the agreement because of the risk that it might not be possible to define a practical procedure.

Yours,
Joel

At 02:55 AM 10/9/2006, Harald Alvestrand wrote:
Simon Josefsson wrote:

To understand what I mean with a compromise between 1 and 2, consider this situation:

We require RFCs to be modifiable, but invent a new document serie "RFC
Attachments" which is permitted to contain non-free material, because
such material may be useful for implementers.  The attachments could
be stored in a file RFC4711-foobar.txt.  Then, it would be legal to
include the RFC itself in free software, as long as you don't also
store the RFC attachment in the free software.

This approach would solve the problem Harald mentioned that, to the
extent this really is a problem, it is difficult to read and implement
an RFC without exposing yourself to reading copyrighted code that you
can't use.

Of course, this was a strawman that may have obvious problems, but I
don't want to assume that it is impossible to solve those problems.

A strawman that would fit much better with what I percieve as the possible consensus of this WG would be to require that RFCs *not* be modifiable, and that all modifiable parts were in attachments. Would this be acceptable to you?
/Simon

[1] I consider the assumption that we must distinguish between code
and text a mistake, people have attempted to derive useful definitions
of code and text and failed before.  Until the WG is approaching a
solution to this problem, I'd continue advocating a simpler solution
(entire modifiable RFCs) because I believe we won't find a good
solution to the problem of separating code and text.





_______________________________________________
Ipr-wg mailing list
Ipr-wg at ietf.org
https://www1.ietf.org/mailman/listinfo/ipr-wg