Simon Josefsson skrev:
> Regarding -outbound section 4.3:
>
> IETF contributions often include components intended to be directly
> processed by a computer. Examples of these include ABNF definitions,
> XML Schemas, XML DTDs, XML RelaxNG definitions, tables of values,
> MIBs, ASN.1, or classical programming code. These are included in
> IETF contributions for clarity and precision in specification. It is
> clearly beneficial, when such items are included in IETF
> contributions, to permit the inclusion of such code components in
> products which implement the contribution. It has been pointed out
> that in several important contexts use of such code requires the
> ability to modify the code. One common example of this is simply the
> need to adapt code for use in specific contexts (languages,
> compilers, tool systems, etc.) Such use frequently requires some
> changes to the text of the code from the IETF contribution. Another
> example is that code included in open source products is frequently
> licensed to permit any and all of the code to be modified. Since we
> want this code included in such products, it follows that we need to
> permit such modification. While there has been discussion of
> restricting the rights to make such modifications in some way, the
> rough consensus of the IETF is that such restrictions are likely a
> bad idea, and are certainly very complex to define.
>
> As such, the rough consensus is that the IETF Trust is to grant
> rights such that code components of IETF contributions can be
> extracted, modified, and used by anyone in any way desired. To
> enable the broadest possible extraction, modification and usage, the
> IETF Trust should avoid adding software license obligations beyond
> those already present in a contribution. The granted rights to
> extract, modify and use code should allow creation of derived works
> outside the IETF that may carry additional license obligations.
> ...
>
> I believe the intention here is good, but it leaves the IETF Trust with
> no guidelines on how to write the license declaration that is likely to
> work well in practice with actual products. There are no reference to
> what "open source" means in this context, and references to "free
> software" is missing.
>
> I believe it would be a complete failure if code-like portions of RFCs
> cannot be included into open source and free software products such as
> the Debian project.
>
> To give the Trust something concrete to work with I propose to add the
> following:
>
> To make sure the granted rights are usable in practice, they need to
> at least meet the requirements of the Open Source Definition [OSD],
> the Free Software Definition [FSD], and the Debian Free Software
> Guidelines [DFSG].
>
> For those who fear that this will lead to complexity: releasing
> something that is compatible with those requirements is simple. The
> modified BSD license meets those requirements, as does a number of other
> methods, including releasing the work into the public domain.
>
> The references being:
>
> [OSD] "The Open Source Definition",
> http://opensource.org/docs/osd
>
> [FSD] "The Free Software Definition",
> http://www.fsf.org/licensing/essays/free-sw.html
>
> [DFSG] "The Debian Free Software Guidelines",
> http://www.debian.org/social_contract#guidelines
>
> Thanks,
> Simon
>
This has been considered in the WG and rejected, I believe - it was felt
inappropriate to tie the IETF definitions to other organizations'
definitions. In particular, it was felt inappropriate to do anything
that might be interpreted as permitting copyleft requirements to be
placed on source code from IETF documents.
If the Trust is able to achieve compatibility, I'm all for it.
Harlad
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
