Lawrence Rosen wrote:
Margaret Wasserman wrote:
Disclaimer: IANAL, and I apologize if I am misunderstanding
something about the license you referenced, but...
It seems to me that the "Non-Profit Open Software License 3.0", while
fine for the source code to IETF tools, places more restrictions and
more burden on someone who uses the code than we would want to place
on someone who uses a MIB, XML schema or other "code" from our RFCs.
For example, the license places an obligation on someone using the
source code to distribute copies of the original source code with any
products they distribute. Effectively, this means that anyone who
distributes products based on MIBs, XML schemas or other "code" from
RFCs would need to put up a partial RFC repository. Why would we
As the author of the Non-Profit Open Software License 3.0 (NOSL 3.0),
perhaps I can clear up some misconceptions about it.
* NOSL 3.0 is for software tools; it is not a standards license. It is not
used as the outbound license for any code in RFCs,
I understood Ray Pelletier to be suggesting that as a possibility, since
he said: "Is it clear that the contributions contemplated by these
documents would require a different treatment?" Which I took to mean
that NOSL 3.0 might be applied to the code snippets contained in RFCs.
and thus there is no
obligation that I'm aware of to put up a "partial RFC repository" anywhere.
Not yet. :)
* NOSL 3.0 does not obligate someone merely "using" the source code or the
software to distribute anything at all.
However, the same does not apply to Derivative Works.
* Source code must be made available by anyone who actually distributes the
software or derivative works thereof to third parties. (The definition in
NOSL 3.0 of "distribution" is important but not relevant to this thread.)
* Source code need not be distributed "with" products containing that
software. Typically, distribution of source code is handled through separate
links on websites, just as most open source software companies now
distribute software and source code.
* Products that incorporate unmodified copies of NOSL 3.0 software tools
rather than derivative works thereof can just inform customers to link to
the IETF website itself for source code. That also serves as a way for IETF
and its contributors to receive credit for writing that free and open source
software in the first place.
* The reciprocity obligation for derivative works and patents in NOSL 3.0 is
on purpose. Everyone is free to use those software tools for any purpose
whatsoever, but improvements to them *that are distributed to third parties*
must be returned to IETF for the potential benefit of other members of the
That all makes perfect sense for the code produced by the Tools Team.
* As you may have seen in recent discussions about the proposed IETF IPR
policies, one goal is to allow anyone to create and distribute products that
embody IETF standards under any license whatsoever. Whatever the outbound
license turns out to be for RFCs, it will presumably not dictate or limit
the license terms for products embodying those RFCs. For that reason alone,
NOSL 3.0 is not appropriate for RFC outbound licensing.
Further information about NOSL 3.0 and related licenses, is at
For various reasons, AFL 3.0, also described in that paper, would perhaps be
a more appropriate outbound license for code in RFCs, but that too is a
topic for a potential separate thread.
Thanks for the clarifications.
Description: S/MIME Cryptographic Signature
IETF mailing list