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

["todd glassey" <tglassey at earthlink.net>]

Per WIPO the  addition of the Code to the Document in any form makes it an
INDUSTRIAL DESIGN and not something alone that Copyright controls. This is
an issue since the entire suite of protections the IETF has are specific to
use statements that are tied to copyright assignments and so ineffective
since they don't control the other Industrial Design Rights.

Todd Glassey

----- Original Message ----- 
From: "Joel M. Halpern" <joel at stevecrocker.com>
To: <ipr-wg at ietf.org>
Sent: Monday, October 09, 2006 7:45 AM
Subject: 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


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