>> I agree that is one solution. I don't think it is
a good one. Code
>> may be tightly integrated with the text and
separating them may
>> decrease the readability of standards. It also
create new problems,
>> like how to handle revisions and errata. We have a
process for that
>> with RFCs, even if it sometimes work less than
perfect. Creating
>> another standardization path within the IETF seem
sub-optimal to me.
>
> I don't think John's proposal would do that, in fact,
but there's
> an easier way, which is <code>...</code>
tags in the text. That has
> another
> advantage - it answers the question "what is
code?" existentially:
> code is the stuff between the tags. Take that as a
model, and we
> can concentrate on the harder question: can we devise
two different
> license regimes, one for code and one for text?
I agree that knowing what is between
<code>...</code>, or perhaps between
<derivedOK>...</derivedOK> tags, would be
useful, no matter what use
(separate repository, pointer to different licencing,
whatever). Using
<derivedOK>...</derivedOK> tags would let us
bypass the "what is code?"
discussion.
I can see someone popping up in ten years and saying,
"we have a new and
exciting way to use ASCII characters extracted from RFCs,
this is clearly
code, even though the participants had no idea it was code,
ten years ago".
Isn't "covered under a different licence" what
we're trying to capture?
Thanks,
Spencer
_______________________________________________
Ipr-wg mailing list
Ipr-wg ietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg
|