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

Simon Josefsson wrote:
>> So the BSD license may have the same problem as the
GPL license in
>> this regard.
>>     
>
> Right.  That's why I suggest that a "IETF source
code license" may be
> a poor idea, especially if that would preclude the
ability of
> including BSD/GPL code in RFCs.  Source code in RFCs
are useful.
>
>   
I have a problem understanding the consistency of your
stance.

You've fought long and hard for NOT permitting the
publication of source 
code in RFCs where modification was impossible. Why wasn't
that useful?

Harald

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

Harald Alvestrand <haraldalvestrand.no> writes:

> Simon Josefsson wrote:
>>> So the BSD license may have the same problem as
the GPL license in
>>> this regard.
>>>     
>>
>> Right.  That's why I suggest that a "IETF
source code license" may be
>> a poor idea, especially if that would preclude the
ability of
>> including BSD/GPL code in RFCs.  Source code in
RFCs are useful.
>>
>>   
> I have a problem understanding the consistency of your
stance.
>
> You've fought long and hard for NOT permitting the
publication of
> source code in RFCs where modification was impossible.
Why wasn't that
> useful?

Someone had the same reaction privately, so I suppose I
should explain
my stance.  My preference is, in order of priority:

1. RFCs (entire RFCs [1]) should be free to distribute and
modify,
   under specific conditions required to solve the problem
of modified
   works implying or claiming to be the real work.

2. Having code in RFCs is better than having no code in
RFCs,
   regardless of license.

I realize that it may be the case that some aspects of 2
work against
some aspects of 1, and depending on your priorities, you'd
might
change 2 into "non-free code is worse than no
code" and then this
issue becomes a non-issue.  I could see good arguments for
either
case.

I don't want to a priori assume that 1 and 2 are mutually
exclusive
goals.  There may be an intersection that is acceptable.

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.

/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-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg

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-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg

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-wgietf.org
https:/
/www1.ietf.org/mailman/listinfo/ipr-wg

--On Monday, 09 October, 2006 10:45 -0400 "Joel M.
Halpern"
<joelstevecrocker.com> wrote:

> 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.

Of course, if we wanted to go down that path, an alternative
would be to make the RFC complete, but to put everything
that
can be arbitrarily modified into some library somewhere
(maintained by the RFC Editor or otherwise) and create
licensing
rights for the content of the library that was different
from
the rights for the material in the RFC, even though subsets
of
both were equivalent.

As reference to the library from the RFC would make that
library
the effective equivalent of the RFC-plus-attachments
approach,
without the problem pointed out above.

This is _not_ a proposal, merely an attempt to point out
that
(i) that third option is out there and (ii) it has been
discussed before and never definitively accepted or
rejected.

     john


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