Re: #1400 Opinion poll - question draft

[Simon Josefsson <simon at josefsson.org>]

John C Klensin <john-ietf at jck.com> writes:

> Now, with regard to those other rights, you've made a relatively
> big deal (IMO) about adapting code for use in specific contexts,
> e.g., mapping from one programming language or data structure
> representation to another.   I think those are non-issues and
> should be dealt with by (explicitly if necessary) simply making
> them special cases of "translation" above.  You should check
> with Jorge, but I believe that there is some case law supporting
> interpreting those types of modifications as "translation", even
> without very explicit definitions.

If we know what we want to achieve, why bury that under "translation"
rather than spelling it out explicitly?  Doing so will lead to
confusion and re-interpretations later on, when the original consensus
is no longer visible.

In general, I do not believe "translations" can cover what we want to
permit, especially under international copyright laws.

Others have already pointed out examples, and the obvious one that I
see in software I work with every week is to fix bugs and adapt code
from an RFC into a particular code style used in a particular project.

A concrete example: I took the Punycode code in RFC 3492 and adapted
it to the coding style I use in LibIDN.  If RFC 3492 would have been
licensed under RFC 2026, RFC 3978 or under a license that only permits
"translations", this would not have been possible.  Fortunately, Adam
Costello wisely placed RFC 3492 under a liberal license:

   Regarding this entire document or any portion of it (including the
   pseudocode and C code), the author makes no guarantees and is not
   responsible for any damage resulting from its use.  The author grants
   irrevocable permission to anyone to use, modify, and distribute it in
   any way that does not diminish the rights of anyone else to use,
   modify, and distribute it, provided that redistributed derivative
   works do not contain misleading author or version information.
   Derivative works need not be licensed under similar terms.

That clause alone enabled me to use the code.  In a later rfc3492bis
draft document, many of the changes I made were incorporated in the
document.

That clause made the IETF help speed up implementation of its
specifications, and got a higher quality specification in return.  I'd
say that's the way to go, not to disallow code-reuse from RFCs.

/Simon

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