[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)

I think I see where at least part of my concern comes from.
I don't agree with your item 2.
I can easily imagine several different licenses that would be very bad to have in an RFC. Hence I disagree strongly with your statement that "[H]aving code in RFCs is better than having no code in RFCs, regardless of license."

To give two examples, a license that said 'if you use this code in your product, you must give away the source to your entire product" would be unacceptable to me. Equally, a license which said "if you use this code, you must license all intellectual property in the product to company X." I can imagine many other unacceptable licenses.
As was recently mentioned on the list, it is very hard to avoid claims of contamination by code published in an RFC.

Hence, there is no way we can simply allow any and all licenses.
Getting into a debate about which licenses we can allow would be a disaster. I doubt we could agree. (I expect that some people disagree with what I consider unacceptable above.)

That is part of why we decided on no restrictions for code.

There is no problem with having restrictions on things that are referenced (particularly informational references) in the RFC. And there is no need for such items to be published by the IETF, as such references can point anywhere one wants. My concern is with code that we consider to be part of the RFC (MIBs, ASN.1, sample algorithms, etc...)

Yours,
Joel M. Halpern

PS: If the IAOC comes back to us and says that they can not craft legal language and procedures to do what we say, then we will have to consider alternatives. But given taht there have been suggestions of ways that may work to accomplish the working group agreement, I see no reason to push for a change based on the possibility it may be hard to craft a practical implementation.

At 04:52 AM 10/7/2006, Simon Josefsson wrote: 
Harald Alvestrand <harald at alvestrand.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-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