On 04/30/2009 03:38 AM, Rahul Sundaram wrote:

Hi

I know there are differences in legal policies but there might be common problems as well.

http://www.mail-archive.com/gnewsense-dev@nongnu.org/msg00125.html

So, looking at that list:

* afio: Yeah, we know about this one. Not in Fedora, caught it on review. * texlive-base, texlive-latex-base: Yes, we're aware of it, auditing it is a nightmare, but I plan to revisit it in earnest after Fedora 11. * libsnmp-base: This is net-snmp (In Lenny, this is 5.4.1, in Rawhide, we're at 5.4.2.1). This is about the MIB files derived from IETF RFCs. The license for IETF RFC docs says:

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

As the MIBs are clearly derivative works, they are available as derivative works that "assist" in the implementation of the various RFCs, without restriction of any kind. Unfortunately, the paragraph is confusingly worded, as they almost certainly mean for "the document" to mean the original RFC from which the work is derived. In addition, these MIB files are arguably in a gray area between Documentation, Code, and Content. I'm going to interpret them as Content, since they serve simply as reinterpretations of the published standard. It would be nice for the IETF to fix this, but as no obvious "code" is under these terms, it is less of a problem.

* libsmi: Same issue as libsnmp. * pike: Not in Fedora. * gkrell-snmp: I don't think this is in Fedora, but it is resolved with upstream adding the OpenSSL exception clause in 1.1.

~spot